AI-led onboarding

Right now a new user has to understand what an application is before they can make one. Which means understanding what an instance is. Which means knowing hosted from remote. They've got no basis for any of it, because they haven't built anything yet.

Step 2 of the create form is the clearest version of the problem: it asks for an instance name, an instance type and a Node-RED version. A brand-new user can't have an opinion on any of the three.

So let's flip it. Get them onto something that runs as fast as we can, then explain what everything is once they've got something to point at.

### What that looks like

After team creation the Expert opens a conversation and does the setup itself. It asks about the work ("where's the data coming from", "what do you want to see at the end"), never about applications or instances, and works out the names and types on its own. Provisioning happens in the background while the conversation carries on. Once there's a plan the user is happy with, it builds, and then it tells them how to actually call the thing it made: real curl, the dashboard URL, the broker and topic, whatever fits what got built.

Anyone who'd rather do it themselves clicks a button and gets exactly what they'd have got before.

All of it sits behind a hidden platform config flag, off by default, Cloud first. Whether we ever expose that to self-hosted is a separate conversation.

### Worth knowing before picking up a task

A few things we confirmed while scoping that shaped the design:

* Plan mode blocks write tools in code, and `invoke_write_tool` isn't even bound while planning. So the agent can't provision while it's still planning. Onboarding provisions first, then plans.
* Flow building only works when the user is inside the immersive editor (`capabilities.push('flow_building')` needs `scope === 'immersive'`). On a team page the agent can't write a node.
* **Deploying stays a human action, deliberately.** Deploy means immediate execution of whatever is on the canvas, so an agent that could deploy could run arbitrary code with the instance's credentials and reach anything that instance can reach, including dropping databases. The user reviews what was built and presses Deploy themselves. So the agent builds, then asks. Blueprint-seeded flows are the exception, since those are live at boot and were reviewed when the blueprint was published, which is part of why blueprints matter here.
* `completeUserSignup` provisions at email verification from a global setting, before the user has expressed any intent.
* The agent can't currently start a turn at all. `Verify input` rejects anything without a `payload.query`.
* A trial permits exactly one instance today. `billing/Team.js` throws `billing_required` on the second. Worth settling with product whether one is still the right number now that the Expert is doing the setup, since it may want more than one to build something useful. Either way the agent needs to know the limit so it doesn't try for a second and surface an error at the user.

### Not in scope

* Chat persistence. Resuming means resuming the plan, not the transcript.
* Platform-concepts education. The welcome tour gets suppressed on this path and nothing replaces it for now.
* The Expert's context handling. It summarises late and cumulatively, which is worth a look on its own, but not here.

Not all of this needs to land together.