Stop the terminal's WebView painting over the setup screens

The shell layered its setup and unlock screens over the terminal, which does
not work: NativeWebView attaches a real Win32 child HWND through
NativeControlHost, and a child window composites above everything its parent
paints regardless of visual-tree z-order. The cards rendered sliced at the
terminal column's left edge; at the window's default width every one of their
buttons fell inside the WebView's rectangle, so the flow could only be
completed by keyboard, and a click in that region handed Win32 focus to
WebView2 so the text boxes silently stopped accepting keystrokes.

The WebView is now collapsed while the vault is not unlocked. The comment
that previously forbade this — hiding it means never realising it — was
wrong: NativeControlHost creates the native attachment on attach to the
visual tree, never consulting layout or visibility, and NativeWebView replays
a Source assigned before its adapter exists. A collapsed WebView still starts
WebView2, loads the page and lets the renderer attach. Confirmed: 35
msedgewebview2 processes with the control collapsed. What the first
connection after unlocking actually depends on is the existing await on
WaitForRendererAsync, since the data plane drops frames when no renderer is
attached.

Also fixes the second visible defect: the default server URL was
https://localhost:7217, the API's *second* launch profile, while the README,
its appsettings and a plain `dotnet run` all use http://localhost:5233 — so
nothing was listening, and an HTTPS client against a plaintext port reports
"The SSL connection could not be established", which reads as a certificate
problem. The default now matches, a missing scheme is rejected by name
instead of parsing as scheme "localhost", and that specific TLS failure now
suggests http://. Both new tests fail when the fixes are reverted.

Corrections to claims I made earlier and should not have:

- docs/platform-flags.md asserted the opposite of the mechanism above and
  cited an established msedgewebview2 connection as verification. That
  observation was taken while the overlay was showing but, because of this
  very bug, the WebView was uncovered and in plain view — so it confirmed
  only that a visible WebView is realised. A process-level check cannot
  verify a rendering claim. The entry was also filed under "Local cache".
- ITerminalHost was documented as the live seam the app plugs into, with a
  stub standing in for headless tests. It has no implementation anywhere and
  no test uses it; the view navigates the control directly. It also counted
  Avalonia.Controls.WebView and NativeWebView as two interchangeable
  backends when they are one component, with the Linux backend backwards.
- The README claimed the shell's whole path was covered by tests. Its state
  machine is; its layout is covered by nothing, and a headless test could
  not have caught this — headless has no native window, so it would have
  rendered correctly and confirmed the wrong belief.

Verified by screenshotting the running app: the card renders complete and
centred at the default size, with the button clickable.

README.md

@@ -173,9 +173,16 @@ off-Windows.
   *Client done:* the key hierarchy, the OIDC flow with the key binding, SSH connections with host key
   trust, the terminal data plane, the encrypted local cache with the sync client — offline unlock, an
   outbox and a field-level three-way merge, conflict matrix green — and an Avalonia shell that is
-  vault-backed: server URL → browser sign-in → enroll → unlock → host list → terminal. The shell's whole
-  path is covered by tests against an in-memory server, so the states that matter most (the recovery code
-  that cannot be skipped, the unlock that needs no network) are checked rather than remembered.
+  vault-backed: server URL → browser sign-in → enroll → unlock → host list → terminal. The shell's *state
+  machine* is covered by tests against an in-memory server, so the states that matter most (the recovery
+  code that cannot be skipped, the unlock that needs no network) are checked rather than remembered.
+
+  Its *layout* is not covered by anything, and that gap has already cost a shipped defect: the setup and
+  unlock screens were layered over the terminal's WebView, which on Windows is a native child window that
+  cannot be covered, so they rendered sliced with their buttons unclickable. No test in this repository
+  loads a `.axaml` file, and a headless one could not have caught this — there is no native window in
+  headless, so it would have rendered perfectly and confirmed the wrong belief. Screens get looked at, or
+  they are unverified.
   *Verified end to end:* `tests/DodoSSH.SystemTests` drives the whole slice against a real Keycloak, a
   real API, a real PostgreSQL and a real `sshd` — sign-in, the identity-provider key binding, enrollment,
   offline unlock, a host through the vault to a second machine, and an interactive shell. See