fix(dsh-role-model): settings panel - representable channels, no hang on Apply, Remote read via ctx.get

[try-works]

Three defects in the role-model settings panel, all reported from live use.

1. The channel select could not represent production

The select offered only [unset, 3457, 3458] — production 3456 was filtered out, on the reasoning that choosing the default was the same as leaving the field alone. That made port: 3456 unrepresentable, so the <select> carried a value no <option> had and the control rendered with nothing selected.

Production is now first-class and the sentinel says what it does:

unset — keep the endpoint field (defaults to :3456)
production — role-model (:3456)
stage — role-model-stage (:3457)
development — role-model-dev (:3458)

2. Apply could sit on "Applying…" forever

Host-side root cause: the settings write runs inside the loader's exclusive queue (config-editor:153 -> hmr.runExclusive), an unbounded FIFO (hmr/src/index.ts:139-147) with no deadline. A write issued while another profile mutation is in flight is queued rather than refused, and its promise does not settle until that operation finishes. Observed live: package.json.lock created the same second as dsh plugin --profile web add @try-works/dsh-stt@0.2.0, held for minutes, profile still holding the old value.

The plugin cannot fix the host queue but must not hang on it: writeConfig now bounds its wait (20s default), and onApply clears saving outside the happy path.

3. cannot get property "remote" without inject

The guard meant to make the Remote optional assumed ctx.remote answers undefined when absent. On the real client context it throws; ctx.get is the lookup that answers undefined. So settingsRemote threw on both paths:

• readConfig rejected, and it was called as void readConfig(ctx).then(...) with no catch, so the failure was silent and the form never seeded — hence the blank endpoint / selectedAlias / providerRoute / requestTimeoutMs fields.
• writeConfig rejected before its own try, so Apply surfaced the raw Cordis message. It only became visible because fix 2 made onApply report failures rather than freeze.

settingsRemote now reads ctx.get("remote") inside a guard. The client half keeps injecting only slots.

Note on the control: the Remote is injectable — the harness's own ui-agent-preset injects 'remote' and 'remote.settings'. This half stays on ctx.get because it must still render when the Remote is missing.

Tests

• every RUNTIME_CHANNELS port must appear in CHANNEL_OPTIONS (RED: "channel 3456 is not selectable")
• rendered option list is [0, 3456, 3457, 3458], with production/stage/development labels
• a write the host accepts but never answers yields a message instead of hanging (RED: test timed out)
• the client context double is now faithful to Cordis — a throwing remote property plus a working get — which reproduced the reported error exactly: six specs failed with cannot get property "remote" without inject before the fix

Suite: 409 passing; tsc and biome clean.