Spec: customer-facing repo-provisioning status surface (provisioning/ready/failed)

[JSONbored]

Decision (ratified 2026-07-21): reuse #7654's already-decided GET /v1/tenants HTTP transport as the polling surface — no new endpoint needed. Customer dashboard polls every 3-5s while in "provisioning", stops on a terminal state.

States shown to the customer, mapped to #7180's real lifecycle vocabulary (control-plane/src/tenant-provisioning-driver.ts's TenantLifecycleState):

• "provisioning" -> "Setting up your instance" (in progress)
• "active" -> "Ready" (terminal, stop polling)
• "failed" -> "Setup failed" (terminal, stop polling) -- new value, does not exist in TenantLifecycleState today. Provisioning core: create/destroy a tenant's Container + Postgres DB #7180's provisionTenant (control-plane/src/provisioning.ts) currently only pages (Wire real PagerDuty alerting into control-plane provisioning failures #7667) and rethrows on failure; it never persists a failed state, so a customer polling today would see the record stuck at "provisioning" forever with no signal. This spec requires provisionTenant's catch block to also transition the tenant record to "failed" before rethrowing, so the polling customer actually sees the failure.
• "suspended" / "torn down" -> out of scope for the provisioning flow specifically (these are post-provisioning operator actions, not part of "setting up"); no new UI needed here beyond what already exists for those states.

Problem

No surface exists for a hosted customer's dashboard to poll their own repo's provisioning state while their Container/DB/webhook-routing are being stood up.

Area

src/api/routes.ts (already has the GET /v1/tenants route per #7654), customer-facing dashboard (alongside #4926/#4927), control-plane/src/provisioning.ts (the new "failed" state transition).

Deliverables

• "failed" added to TenantLifecycleState, set by provisionTenant's catch block before rethrowing (control-plane/src/provisioning.ts).
• Customer dashboard polls GET /v1/tenants/:name (or the list route, filtered) every 3-5s while "provisioning", stops on "active"/"failed".
• The three-state customer-facing copy above (setting up / ready / setup failed).
• Tests: a provisioning failure transitions the record to "failed" and is observable via the same read path a customer's dashboard uses.

Resources

• Provisioning core: create/destroy a tenant's Container + Postgres DB #7180, Real Postgres/Hyperdrive driver for control-plane's provisionDatabase/deprovisionDatabase #7653/Stand up control-plane's real HTTP transport (POST/GET/DELETE /v1/tenants) matching the already-merged client #7654/Real Cloudflare Containers driver for control-plane's createContainer/destroyContainer/containerExists #7851/Real secret-injection driver for control-plane's injectSecrets/revokeSecrets via the generalized broker #7852 (the real driver + transport this reflects)
• Redesign the setup-wizard for true multi-instance self-serve provisioning #4926, Decouple "admin of a GitHub install" from "has a running container" #4927 (the customer-facing provisioning UX this feeds)

Contributor-eligible. Spec is decided above; remaining work is implementing an additional lifecycle state + a polling UI against an already-existing endpoint (#7654), not an open design question.

[linear-code]

JSO-5423