Redesign the setup-wizard for true multi-instance self-serve provisioning

[JSONbored]

Decision (ratified 2026-07-21): the wizard becomes verify -> trigger provisioning (#4927) -> redirect to the status view (#7677), replacing the current one-operator manifest flow. See #4927 for the trigger-side guards (idempotency, one-tenant-per-customer-per-product) this wizard depends on.

Problem: The setup wizard (src/selfhost/setup-wizard.ts) is a one-operator manifest flow today — it assumes the operator already has infrastructure standing up and running, with no real provisioning step.

Area: ORB / Onboarding.

Deliverables:

• Wizard UI calling Decouple "admin of a GitHub install" from "has a running container" #4927's verify-and-trigger flow instead of collecting manifest credentials for pre-existing infrastructure.
• Redirects to Spec: customer-facing repo-provisioning status surface (provisioning/ready/failed) #7677's status-polling view once provisioning is triggered.

Resources

• src/selfhost/setup-wizard.ts (the existing flow this redesigns)
• Decouple "admin of a GitHub install" from "has a running container" #4927 (the verify-and-trigger logic this wizard calls), Spec: customer-facing repo-provisioning status surface (provisioning/ready/failed) #7677 (the status view this redirects to)

maintainer-only — depends on #4927's trigger-side guards actually landing and being correct; sequence after #4927, don't build the UI ahead of the safety gate it depends on.

[linear-code]

JSO-3586

[JSONbored]

Depends on #7180 (shared provisioning core) landing first — this issue is the self-serve UX on top of it, not the provisioning mechanism itself.

[JSONbored]

Related decision (2026-07-21): the customer-facing entry point now has a decided shape — /install forks into BYOR ("connect a repo") vs APR ("describe an idea") at step 1, both gated behind sign-in first. Worth designing this setup wizard's scope consistent with that fork rather than assuming a single linear flow.