Define the questions the Expert asks during onboarding

The onboarding mode changes how the Expert behaves. This is the content: what it actually asks.

Worth keeping separate from the prompt work because it's a different kind of decision. Whether a question is worth asking, and whether its options make sense to someone who has never used Node-RED, isn't really an engineering call.

### Examples to work from

These came out of scoping. Not a proposal, but they're the right shape and the right register, so they're a reasonable starting point.

**Opening, free text rather than options:**

> Most people come here with something specific they want working. What's yours?

**Where the data comes from** (single select)

| Label | Description |
| --- | --- |
| A PLC or machine controller | Siemens, Allen-Bradley, Omron and similar |
| A sensor or gateway already publishing | Usually over MQTT or Modbus |
| A database or an API | Somewhere I can point you at |
| Something else | Free text |

**What they want at the end** (single select)

| Label | Description |
| --- | --- |
| A live screen I can leave up | A dashboard showing current values |
| Alerts when something looks wrong | Only hear about it when it matters |
| The data stored so I can look back | Kept for later analysis |
| Something else | Free text |

**How it should tell them** (multi select)

| Label | Description |
| --- | --- |
| Show it on the same screen | |
| Email me | |
| Post to a chat channel | Slack, Teams and similar |
| Something else | Free text |

The rest of the list goes here. **TODO: add the questions we already have.**

### What each question needs

Per question:

* the question text
* whether more than one answer can apply
* two to four options, each with a label and a description where the label alone would be ambiguous
* what the answer is actually used for, which is the useful discipline: if an answer doesn't change what gets built or how the Expert talks, the question is costing the user something for nothing

### Constraints from the renderer

* At most four questions per turn, at least one.
* Two to four options per question. Not one, not five.
* Options are labels the user taps, so short. One to five words.

Those are limits in the existing schema rather than choices we've made here, so a longer intake has to span turns.

### Worth knowing

None of the questions can use platform vocabulary. That's the whole point of the flow, and questions are where it would leak in most naturally, because it's tempting to ask "how many instances do you need" when what you mean is "how much are you building".

Order matters more than it looks. If one answer would make another question pointless, ask that one first and alone. The routing policy already pushes the Expert toward asking the fewest questions that unblock the work, so a long fixed list will fight it.

The answers feed two things: the setup the Expert picks silently, and the traits it uses to decide how technical to be when it talks. So it's worth being explicit about which questions serve which, since a question that serves neither is just friction.