Stop the relay checkbox promising a connection this client cannot make

Ticking "Connect through the server relay" moved the host's address and port out of the encrypted payload
into plaintext columns on the server — the single deliberate privacy concession in the design, per ADR 0004
— and then the client dialled the address directly, exactly as it does with the box clear. VaultViewModel
builds SshConnectionRequest(hostname, port, username, credential) and nothing on this side reads
RelayEnabled at all. The connection failed the way it always had, for a machine the laptop could not reach,
with nothing saying the box had done nothing.

The server half is built and shipped: tickets, the WebSocket, the deny list, the CHECK constraint that
enforces a non-null address for a relay-enabled host. What does not exist is the client's path to it, so
this is an unfinished feature rather than a broken one — but the control in front of it was collecting the
cost of the finished version.

Both heads now say so, in the label and in the first sentence of the paragraph under it. Not disabled, and
that is the one decision here worth stating: a host somebody has already ticked has to be able to lose the
flag, and a control greyed out with the concession switched on would trap it there. Tickable and honest
beats untickable and stuck.

This is step 0 of docs/reaching-a-host-you-cannot-dial.md, and the only step of it that should ship alone —
the sentence is written to be deleted when the bridge lands.

VERIFIED. Build clean, 112 layout tests. The drawer's paragraph is longer than it was and the host editor is
measured with the drawer open at the window's minimum, so the wrap is held inside the column rather than
assumed to fit.

docs/reaching-a-host-you-cannot-dial.md

@@ -12,11 +12,11 @@ This document is the comparison between them, which is the thing that has to be
 built, and then the plan. It replaces an earlier draft of `docs/jump-hosts.md` that recommended deleting the
 jump chain — see the last section for why that was wrong.
 
-> **Status: planned, nothing started.** Step 0 is a one-line honesty fix and should not wait for the rest.
+> **Status: step 0 done, the rest planned.**
 >
 > | Step | State | Notes |
 > | --- | --- | --- |
-> | 0. Stop promising the relay | Not started | The checkbox is wired to storage and to nothing else |
+> | 0. Stop promising the relay | **Done** | Both heads say the box is not wired up and that ticking it stores the address and changes nothing. Left tickable, so a host already carrying the flag can lose it |
 > | 1. The loopback bridge | Not started | ADR 0004's "one mechanism, two features" |
 > | 2. Jump hosts over it | Not started | No server change at all |
 > | 3. The relay over it | Not started | Ticket call, WebSocket, then the same bridge |
@@ -38,9 +38,13 @@ design, per ADR 0004 — and the connection is still made from their laptop to t
 not reach. It then fails exactly as it did before, with no hint that the box did nothing.
 
 This is worse than the jump chain, which is invisible and harmless. It is a control that spends something
-real. Step 0 exists because it should not survive another release in that state, and it is one line: the
-checkbox says the relay is not wired up yet, the way this codebase already handles port forwarding on the
-phone's More screen.
+real.
+
+**Step 0 is done.** Both heads now name the absence in the label and lead the paragraph under it with what
+ticking the box actually does today — the way this codebase already handles port forwarding on the phone's
+More screen. It is left *tickable* rather than disabled, deliberately: a host that already carries the flag
+has to be able to lose it, and a disabled control would trap the concession on. The sentence comes out again
+at step 3.
 
 ## The comparison