CL-6457: Provider connect must not deploy anything

[TheGreatAxios]

Pasting an Anthropic key on onboarding sat on a static "Connecting…" for over two minutes. The connect request was deploying five default workflows — around twenty seconds each — before it answered. Long enough to read as frozen.

Connecting now deploys nothing.

What connect does now

Connect keeps only the durable, fast half: persist the credential, seed its model catalog, answer. Deploying a bench's default workflows moves to a background drain, and no HTTP route deploys anything any more — POST /complete and POST /complete-setup both report where the agents stand and hand the work off, and a new GET /api/onboarding/provisioning-status serves anything that needs to poll.

completeCredentialSetup still composes both halves for harnesses that need a fully deployed bench before a scenario begins (@workbench/evals' real target), and its comments now say plainly that a route calling it re-creates the freeze.

Why the drain converges

It is not a job queue. It is a pass over onboarding.pending_seed, where the row is the work item and means "this bench has a credential and does not yet have its agents". The properties fall out of that framing:

• Idempotent — every pass re-reads the bench's real asset and deployment state first, and seedTenant underneath is ensure-then-create. A pass over a finished bench deploys nothing and clears the row.
• Convergent — a pass that gets partway leaves the row, so the next one picks up exactly what is still missing.
• Restart-safe — no outstanding work lives in the process. A hub that dies mid-deploy leaves the row behind and the next boot's first tick finishes it. In-memory state is only ever a dedupe guard or a retry backoff.

A failing bench backs off (15s, doubling to a 10-minute ceiling) rather than hammering a down sidecar, and is never dropped for failing.

Sessions

A background loop has no request to borrow cookies from. The provisioner takes sessionFor as a seam and the hub fills it by minting the bench owner's own session in process. It has to be the owner's: the hub resolves a tenant by looking up a principal for that user, and rights do not flow from a parent org to a child bench, so an administrator would simply be refused. These sessions carry a workbench-bench-provisioner user agent so they are never mistaken for a human sign-in, and are cached per user rather than minted per tick.

What someone sees

Connecting hands the person forward immediately. If they land before their agents exist they get the warm loading state — "Getting your agents ready…" with live progress, N of M ready — which resolves into their workbench on its own. Whether the bench is still provisioning is asked of the bench rather than read off an error message: still deploying is someone waiting, not someone broken. This closes a real hole, since the zero-workbench land path previously threw "No default setup agent found" and showed an error card.

Tests

The headline test is a clock, not a mock: the deploy step is a seam that takes five seconds, and connect has to answer in under one without that seam ever starting. A route that awaits a deploy again fails on elapsed time.

Alongside it: drain idempotency, convergence of a half-provisioned bench, restart-resume by a fresh provisioner with empty memory, no double-deploy under overlapping passes, backoff, and the client's connected/pending rendering.

Scoped green — packages/onboarding 149 pass / 0 fail, apps/web 748 pass / 0 fail, apps/hub 137 pass / 0 fail, typecheck and lint clean across all three.

Fixes CL-6457