Have the Expert set up the workspace from the conversation

This is the part that does the actual work. The user has said what they're trying to get running, in their own words, and the Expert turns that into a working setup without ever making them choose an instance type.

Four pieces:

* **Give the Expert an onboarding mode that never asks about platform concepts.** The behaviour change: no vocabulary, silent defaults, one instance, provision before planning.
* **Define the questions the Expert asks.** The actual content. Which questions, in what order, with what options.
* **Have the Expert check whether the workspace has finished starting.** So it knows when the instance is ready to be built into.
* **Put the new instance in the Expert's context so it can navigate to the editor.** Otherwise the existing navigate-to-editor behaviour stays switched off.

### Worth knowing

The order matters and it's forced on us. Plan mode blocks write tools in code, and `invoke_write_tool` isn't even bound while planning, so the Expert cannot create anything while it's still planning. Onboarding therefore runs in two phases: gather intent and provision with plan mode off, then turn plan mode on to work out what to build inside it.

One consequence of that worth flagging: with plan mode off during phase one, every write tool is available, not just the provisioning pair. On a brand-new empty team there's nothing to damage so it doesn't matter much, but it stops being harmless if we ever put this flow in front of an established team.

The tool descriptions currently work against us here. `platform_create_hosted_instance` tells the agent to "ask the user which one they want" for instance type, to "ask the user which one to use" for template, and not to pick a name itself but to "propose a few alternative options and let the user choose". `platform_create_application` similarly says to ask before reusing an existing application. All of that is correct behaviour normally and exactly wrong during onboarding, so the onboarding mode has to override it without changing how the Expert behaves everywhere else.

Blueprints matter more than they look. A blueprint passed as `flowBlueprintId` at creation time is live when the instance boots, with no deploy step needed. Anything the Expert authors by hand afterwards sits inert until the user presses Deploy. So how good the first impression is depends partly on whether a blueprint fits what the user asked for.