OpenAI provisioning + key-policy consolidation for n1x

# Add OpenAI platform support and consolidate service-account key policy

Two pieces of work that land together.

## 1. OpenAI capabilities

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 the app id, creates an `<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, the runtime key flows through the existing
`TF_VAR_web_secret_env_values` map. Never expose either credential through a
`NEXT_PUBLIC_*` variable.

- `web-openai` works without `infra`.
- `openai` with `infra` does not introduce the web SDK or runtime key.
- Projects that select neither capability gain no OpenAI output.

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.

## 2. Key-policy consolidation

Three existing capabilities need Google service-account keys, and each
currently carries its own copy of the key-creation policy Terraform: `gemini`,
`web-gcp-identity`, and `web-job-runner`.

Consolidate that ownership: key-creation policy Terraform must resolve to
exactly one neutral shared prerequisite, `gcp-service-account-keys`, required
by every consumer, rendering the same single owners at the same Terraform
addresses regardless of which consumers are selected or in what order. The
prerequisite must not itself require `infra`, and consumers keep working
without `infra`.

Deployed projects already hold the legacy policy objects in remote Terraform
state — under each consumer's own historical addresses. Regenerating any
existing project must never propose destroying and recreating those remote
objects, whichever consumer or combination the project was created with.

Lifecycle: removing any subset of consumers preserves the shared objects for
the consumers that remain; removing the last consumer cleans them up
completely; projects with no key consumer never gain them.

## General expectations

Repeated apply operations are idempotent and preserve project-owned edits.
Implement everything through n1x's existing declarative plugin actions. The
core engine and unrelated capabilities must remain byte-for-byte unchanged;
repository documentation (`README.md` and `AGENTS.md` guidance templates) may
be updated freely. Update downstream lint coverage and smoke coverage so the
new capabilities, the shared prerequisite, multi-consumer composition, and
clean removal are exercised while preserving all existing behavior.