feat(build): wire the model provider's API key into generated secrets

[naveen-kurra]

What

Add a build stage that includes the model provider's API-key env var (e.g. OPENAI_API_KEY) in the generated secrets.yaml and deployment.yaml, so a deployed agent can actually receive its provider key.

Why

The provider's APIKeyEnvVar is defined in forge-core/catalog/providers.go (OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY) but is never referenced at build time. The secret-placeholder set (Spec.Requirements.EnvRequired/EnvOptional) is populated only from skills (RequirementsStage) and channels (ChannelsStage). As a result:

• no OPENAI_API_KEY placeholder in secrets.yaml,
• no secretKeyRef env entry in deployment.yaml,
• so the key never reaches the pod and the runtime logs no OpenAI API key … using stub and falls back to a stub LLM.

Change

ModelProviderStage (runs after ChannelsStage): looks up Config.Model.Provider in the catalog and appends its APIKeyEnvVar to Spec.Requirements.EnvOptional.

• Optional, not required — a provider may authenticate via OAuth, and local/custom providers (empty APIKeyEnvVar) need no key. An unset optional secret key is ignored at runtime.
• De-dups against env vars a skill or channel already declares.
• Unknown / keyless providers add nothing.

The existing secrets.yaml.tmpl / deployment.yaml.tmpl already iterate OptionalEnvVars, so no template changes are needed.

Test

• Unit tests (model_provider_stage_test.go): adds the key as optional, populates Requirements when nil, skips when already declared, and adds nothing for keyless/unknown providers.
• gofmt clean; go build ./... clean.
• End-to-end: forge build on an openai agent now emits OPENAI_API_KEY: "" in secrets.yaml and an OPENAI_API_KEY secretKeyRef (optional) in deployment.yaml.

Impact

Operators (or the initializ build/deploy pipeline's SECRET_VARS) can now populate the provider key into the agent's <id>-secrets and it flows through to the pod — enabling real inference instead of the stub.