Lay the phone out like the desktop when the surface is not a phone

Three destinations in a bar and everything else behind SETTINGS is the right
shape at 360dp, where a fourth entry costs the width of the three that are there.
On a tablet, an unfolded foldable or a landscape phone it is the wrong one: there
is room for every destination at once, and the hub becomes an extra tap between
somebody and a screen they can already see space for.

So at 600dp — Android's own boundary between a compact window and a medium one,
in the density-independent units Avalonia lays out in — the bar stands down and
PhoneRail takes the left edge with all nine on it. It is the desktop's NavRail
arrangement rather than its file: the two heads cannot share a view, and this one
draws the phone's destination set with the phone's palette and touch targets.

The flags are computed in code rather than assembled in the markup because none
of them is a single question any more, and Avalonia's bindings have no "and" —
and the header's condition is an "or", which not even a wrapper can express. That
header is the one worth reading twice: narrow it stands down behind SETTINGS, so
the hub's screens can draw their own; wide there is no hub to be behind, so it
stays up everywhere. Losing it on the keychain would be losing the only LOCK
button on the surface.

Removing the hub means removing the routes into it, and there were four kinds.
The rail has no SETTINGS entry, because that screen is a menu of the rail. The
five back arrows in the screens under it are hidden, since an arrow to a screen
the layout removed is the one control on a header that leads nowhere. The system
back gesture goes to Hosts instead. And unfolding while sitting on the hub moves
to Hosts, rather than leaving somebody on a list of things now visible beside it.

One bug fixed on the way: OnBodyResized returned early unless the keyboard was
open, so a foldable would have opened to a phone layout until somebody typed
something. The chrome is refreshed first and unconditionally; the early return
belongs to the older job below it.

What this does not do is use the width *inside* a screen — the host list is one
column at any size. Two columns needs the row model to change, because that list
is headings and hosts in one sequence and a heading has to span, and that model
is shared with the desktop. Check 8.1 walks the rail; nothing here is covered by
a test, for the reason 8.0 exists.

README.md

@@ -553,6 +553,17 @@ does not draw is anything that takes access away: REMOVE and WITHDRAW KEY act on
 irreversible revocation under a thumb with its explanation in a tooltip nothing can show is the wrong
 trade.
 
+**On a surface wider than 600dp it lays itself out like the desktop.** A tablet, an unfolded foldable, a
+phone in landscape or a freeform window gets a nav rail down the left carrying every destination at once,
+and the three-entry bottom bar stands down with the SETTINGS hub it led to — a hub is an extra tap between
+you and a screen there is visibly room for. Below that width nothing changes. The one number is Android's
+own boundary between a compact window and a medium one, measured in the density-independent units Avalonia
+lays out in.
+
+What it does *not* yet do is use the extra width inside a screen: the host list is still one column at any
+size. Two columns needs the row model to change — the list is headings and hosts in one sequence, and a
+heading has to span — which is shared with the desktop and is its own piece of work.
+
 **Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than
 leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so
 every control on that screen would have had no effect. See