Add validation steps in _ai-pr-review.yml to check for missing API keys with clear error messages

What

Add a validation step at the beginning of the _ai-pr-review.yml workflow (before any provider API calls) that checks whether the required API keys (openai_api_key and deepseek_api_key inputs) are set. If a required key is missing, the step should fail with a clear, actionable error message identifying which key is missing and how to configure it.

Why

Currently, if DEEPSEEK_API_KEY or OPENAI_API_KEY secrets are not configured in the repository, the workflow will proceed to call the provider API and fail with a confusing, non-descriptive error (e.g., authentication failure or empty key error). This makes debugging difficult for repository maintainers who may not immediately realize the issue is a missing secret. The pip_install_cicaid_pro.sh script already validates CICAID_PRO_TOKEN, but the AI review workflows lack equivalent validation.

How

1. Add a new step early in _ai-pr-review.yml (before the "Run AI review" step) that:

   • Checks if inputs.openai_api_key is empty when inputs.provider_id == 'openai'
   • Checks if inputs.deepseek_api_key is empty when inputs.provider_id == 'deepseek'
   • If a required key is missing, exits with a non-zero code and prints a clear error message like: "Missing required API key for provider 'openai'. Please set the OPENAI_API_KEY secret in the repository settings."

2. Use a shell conditional or if statement in the step to handle the provider-specific logic, since the workflow is a reusable composite that handles both providers.

3. Consider using env variables to pass the keys and validate them with a simple shell check (e.g., if [ -z "$OPENAI_API_KEY" ]; then echo "::error::..."; exit 1; fi).

Files Affected

• .github/workflows/_ai-pr-review.yml

Constraints

• Must not break existing functionality when API keys are properly configured
• Must not interfere with the continue-on-error behavior of the check_approval step
• Should not add unnecessary complexity — a simple shell check is sufficient
• Out of scope: fixing the misleading condition in the "Fail if provider did not approve" step (separate issue), adding documentation for ENABLE_DEEPSEEK_REVIEW/ENABLE_GPT_REVIEW vars (separate issue)

LLM tier

Sonnet — This requires moderate design judgment to handle provider-specific validation logic in a reusable workflow while keeping the change minimal and non-breaking.

Success looks like

• When OPENAI_API_KEY is not set and a GPT review is triggered, the workflow fails early with a clear error message: "Missing required API key for provider 'openai'. Please set the OPENAI_API_KEY secret in the repository settings."
• When DEEPSEEK_API_KEY is not set and a DeepSeek review is triggered, the workflow fails early with a similar clear message
• When all required keys are set, the workflow behaves exactly as before (no regression)
• The validation step runs before any provider API calls, preventing confusing downstream errors

Failure looks like

• The validation step is added but doesn't actually catch missing keys (e.g., checks the wrong variable or uses incorrect syntax)
• The validation step fails even when keys are properly configured (false positive)
• The error message is vague or doesn't identify which key is missing
• The change introduces a regression in the workflow's normal operation when keys are present

Follow-up from AI review of PR #3.

Implementation notes

FILES: .github/workflows/_ai-pr-review.yml
DONE: Add a validation step at the beginning of the workflow that checks for the required API key based on the provider_id input, failing with a clear error message if the key is missing, while preserving existing behavior when keys are present.