n1x-openai-provisioning

# Add first-class OpenAI API Platform support to n1x

Introduce an `openai` capability which, when composed with `infra`, declares the
official `openai/openai` Terraform provider at `~> 0.7.0`, creates an OpenAI
project named from `local.app_id`, creates a `${local.app_id}-runtime` service
account with the API project-member role, and exposes the project and service
account IDs as Terraform outputs. Terraform must not mint runtime API keys; it
authenticates with `OPENAI_ADMIN_KEY`.

Introduce a `web-openai` capability that requires `web` and `openai`, adds
`openai` `^7.0.0` to the generated web app, and makes the server-only
`OPENAI_API_KEY` part of the normal generated web environment workflow. When
`infra` is selected, pass the runtime key through the existing
`TF_VAR_web_secret_env_values` map. Never expose either credential through a
`NEXT_PUBLIC_*` variable.

Keep the capabilities composable:

- `web-openai` must work without `infra`.
- `openai` with `infra` must not introduce the web SDK or runtime key.
- Existing projects that select neither capability must not gain OpenAI output.
- Repeated apply operations must be idempotent.
- Removing the capabilities must clean up their managed Terraform, environment,
  and guidance insertions according to n1x's existing lifecycle rules.

Document the operator workflow and credential boundary. After provisioning, an
operator creates a scoped runtime key through the OpenAI Admin API and supplies
it through `TF_VAR_web_secret_env_values`; the admin key is only for Terraform
and must never be used for model requests.

Update repository documentation, generated guidance, lint coverage, and smoke
coverage while preserving all existing behavior. Repository documentation
(`README.md` and `AGENTS.md` guidance templates) may be updated freely; every
other engine or capability source outside the disclosed `openai`, `web-openai`,
`web`, and `infra` seams must remain byte-for-byte unchanged.