Deliver secrets/env vars into a running hosted tenant container (OrbTenantContainer/AmsTenantContainer)

[JSONbored]

Problem

No mechanism exists today to deliver a secret or connection string into a running hosted tenant container's process environment — found while investigating #7858 (Neon branch-per-attempt DB fork), but it's a strictly more foundational gap than that one issue.

control-plane/src/secret-driver.ts's own header states this directly: it "ONLY stores/revokes custody of the credential in the broker. It does NOT deliver the secret into a running container's environment -- that's separate, not-yet-built infrastructure." control-plane/src/container-driver.ts's createTenantContainer() only ever passes LOOPOVER_PINNED_VERSION via stub.start({envVars}) — no database connection, no GitHub token, nothing secret-shaped, for either OrbTenantContainer or AmsTenantContainer.

Concretely, this means even the already-shipped tenant-level Neon database connection (control-plane/src/neon-database-driver.ts's DatabaseConnectionDetails.connectionString, real and working since PR #7939) has nowhere to land in a running hosted container today. It's stored in the secret broker's custody and then... nothing delivers it further.

Area

control-plane/src/container-driver.ts (createTenantContainer, ContainerStubLike.start), control-plane/src/secret-driver.ts, control-plane/src/provisioning.ts (injectSecrets step — currently only handles broker custody, not container delivery).

Proposal

Not prescribing a mechanism here — needs its own design pass. Two shapes worth considering as a starting point: (a) stub.start({envVars}) already exists as the injection point Cloudflare Containers expose — injectSecrets (or a new step after it) could resolve the custodied secret and pass it through this same path at container-start time; (b) a pull-based alternative where the container fetches its own secrets from control-plane's own API at boot (mirrors how self-host containers already pull short-lived tokens via src/orb/broker-client.ts's broker pattern, rather than pushing them in). Whichever is chosen needs to work for both OrbTenantContainer and AmsTenantContainer without a product-specific branch, matching this codebase's existing product-agnostic provisionTenant/deprovisionTenant orchestration.

Deliverables

• A decided mechanism for delivering a secret from the broker's custody into a running tenant container's process environment
• Wired into provisionTenant's injectSecrets step (or immediately after it) for both products
• Tests proving a container actually receives the value at start, and that revocation actually removes access (not just broker custody)

Resources

• control-plane/src/secret-driver.ts (the existing custody-only half)
• control-plane/src/neon-database-driver.ts (the first real credential this would need to deliver)
• src/orb/broker-client.ts (self-host's own pull-based token pattern, a possible precedent for option (b) above)
• Neon branch-per-attempt disposable DB fork for APR execution (implements #7649) #7858 (Neon branch-per-attempt DB fork) — its hosted half is blocked by this issue

Boundaries

maintainer-only — new privileged data path into a running hosted container; needs a real design decision on push-vs-pull before implementation, not a default extension of existing plumbing.

[linear-code]

JSO-5688