Split onboarding and classic signups into cohorts from the browser

To know whether the new path is better we need some people getting the old one at the same time. So new signups on a flagged deployment get assigned to one of two cohorts, and the assignment is made in the browser.

The mechanism falls out of how we've built the rest of it. Auto-provisioning at signup is off for everyone on a flagged deployment. So:

* **Onboarding cohort.** Lands in the conversation, and the Expert provisions from what they say.
* **Control cohort.** The browser calls the on-demand provisioning endpoint on arrival, which gives them the application and instance a classic signup always produced, and sends them to the classic team home.

Same endpoint the way-out control uses. Control is effectively the way out firing automatically.

### Done when

* A new signup on a flagged deployment lands in one cohort or the other.
* The control cohort's experience is indistinguishable from a classic signup.
* Which cohort a user is in is attached to their events so the funnel can be split.
* Assignment is stable for a given user across page loads.

### Worth knowing

The reason this is client-side rather than server-side is worth recording. `forge/product/index.js` only decorates `capture`, so there's no server-side PostHog flag evaluation, and the auto-provision decision used to happen at email verification with no browser running. Routing the control cohort through the on-demand endpoint sidesteps both problems without adding server-side flag evaluation, which would otherwise mean signup depending on PostHog being reachable.

The control cohort sees a brief moment before their workspace appears, since it's created on arrival rather than at verification. Worth checking that doesn't read as broken, because if it does it's a difference between the cohorts that has nothing to do with what we're testing.

Stability matters. If the assignment is recomputed on each load, someone could get onboarding on one visit and the classic path on the next, which would poison the data and confuse the user. PostHog handles this if the flag is evaluated per distinct id, but it's worth confirming rather than assuming.

`posthogFlags` already exists on the `account-settings` store, so there's somewhere for the assignment to live.