Give the Expert an onboarding mode that never asks about platform concepts

When the onboarding flag is set, the Expert behaves differently in four ways.

**It doesn't use platform vocabulary.** No applications, instances, hosted, remote, stacks or templates. It asks about the work: where the data comes from, what the user wants to see at the end. Asking "what should we call your application?" in a chat window is the same barrier as asking it in a form, so this is the part that matters most and the easiest to lose.

**It picks the setup itself.** Name, instance type, Node-RED version, template and blueprint all get chosen from what the user said, silently. The user never sees those decisions unless they ask.

**It works out how much it's allowed to create, and stays inside it.** Rather than assuming a number, it reads what the team can actually do and plans around that. What it should never do is attempt something the plan forbids and surface a `billing_required` error at someone who has no idea what billing has to do with anything.

**It provisions before it plans.** Gather intent with plan mode off, create the workspace, then turn plan mode on to work out what to build inside it.

### Done when

* A set of test conversations produces no question about instance type, Node-RED version, template or application naming.
* No `billing_required` error reaches the user.
* The workspace exists before the Expert starts proposing what to build in it.
* Normal support conversations are unchanged.

### Worth knowing

Work lands in the flows on `expert-api-dev`, not this repo.

The tool descriptions actively fight this. `platform_create_hosted_instance` says to "ask the user which one they want" for instance type, "ask the user which one to use" for template, and explicitly not to pick a name itself but to "propose a few alternative options and let the user choose". `platform_create_application` says to ask before reusing an existing application. Those instructions are right for normal use, so this needs to override them for onboarding rather than change them.

For picking defaults: `platform_list_hosted_instance_types` returns a `creatable` flag per type and a `defaultStack` which is the latest recommended version, so there's enough to choose sensibly without asking. `platform_list_templates` gives the template, and the tool description already says to use it automatically when only one exists.

For the limit, there's more than one way to read it. `platform_list_hosted_instance_types` flags whether a type is creatable right now within the team's limits, and `platform_get_team_instance_counts` gives current usage. Between them the Expert can work out its own headroom rather than being told a number.

How many instances a trial should allow is genuinely unsettled and needs a decision with product or leadership. Today `billing/Team.js` permits one on a trial with a pinned instance type and throws on the second. That may be the wrong number now the Expert is doing the setup and might want more than one to build something useful. So this should read the limit rather than hardcode it, which also means it keeps working when the answer changes.

Two mechanical notes. `platform_check_hosted_instance_name_availability` is described as required rather than optional, and skipping it is called out as the most common cause of a failed creation, so silent naming still has to check. And names need hyphens rather than spaces.

This is prompt work inside a function node that's already very large, and it needs iteration against real conversations rather than a single pass. Worth expecting it to take longer than it looks.