Wire the Avalonia shell to the vault

The host list now comes from the vault instead of from a form. A fresh
machine takes a server URL, signs in through the browser, enrolls, and
from then on opens with the passphrase alone.

DodoSSH.Client.Session is the composition layer: where a profile lives,
how it unlocks, and how a machine gets one. ClientPaths picks a
non-roaming per-OS directory — %LOCALAPPDATA% and never %APPDATA%,
because a SQLite cache that roams between two machines is a corrupt one,
and each machine's outbox is its own. SessionOpener needs no transport at
all and could not reach one if it wanted to; that is the offline unlock,
asserted rather than asserted about. A wrong passphrase, a stale KDF and a
grant revoked by a rekey are three different answers, because the remedies
are three different things and telling someone to retype a passphrase that
was never the problem is worse than saying nothing.

The shell's states are the onboarding story. The recovery code gets its
own state that cannot be clicked past: it exists for one moment, losing it
with the passphrase loses the vault, and there is no server-side reset by
design. It is dropped from memory on confirmation rather than merely
hidden.

Sign-in is a delegate over IVaultServer, so the whole state machine runs
in a test against an in-memory server — no browser, no identity provider,
no toolkit. The view models are plain observable objects, which is what
makes that possible. What it does not cover is whether the XAML binds to
the right names; that needs a rendered tree and Avalonia.Headless, and is
its own piece of work.

Three things found by doing it rather than by reading it:

- Pooled SQLite connections keep the database file open after the last
  context is disposed. On Windows that means locked, so the application
  could never replace its own cache — and a test could not clean up after
  itself, which is how it surfaced. Dispose now clears the pool.
- EF's SQLite provider puts the database in WAL mode, so the cache is
  three files. A comment in ClientCacheFactory claimed the opposite;
  reading PRAGMA journal_mode off a real launch settled it. WAL is the
  right mode here — a sync pass writes while the interface reads — so the
  comment was wrong on the merits as well as on the fact.
- Enrolling a device key with nowhere to keep the private half would put a
  wrap on the server nobody can open and make the device list claim this
  machine can unlock without a passphrase. Device binding is now optional
  and the shell declines it until the OS keystore is wired.

Verified on Windows: the client created %LOCALAPPDATA%\DodoSSH\cache.db
and migrated it on first launch, and msedgewebview2 held an established
connection to the data plane while the unlock overlay covered it — which
is the point of covering the WebView rather than collapsing it, since a
NativeWebView that is never laid out is never realised.

630 tests, up from 593. The recovery-code gate and the offline unlock were
each verified by breaking them and watching the right test fail.

Still to do for M1's actual definition of done: the manual run against the
real API and a real Keycloak. Credentials are not a synced entity type
yet, so a connection still asks for a password, and the interface says so
rather than implying otherwise.

README.md

@@ -50,6 +50,7 @@ src/
   DodoSSH.Client.Domain    the decrypted item model and the three-way merge — no I/O at all
   DodoSSH.Client.Storage   the local cache: ciphertext mirror, outbox, offline unlock material
   DodoSSH.Client.Sync      the pull/apply/push loop and the conflict policy
+  DodoSSH.Client.Session   where a profile lives, unlocking it, and getting one in the first place
   DodoSSH.Client.Ssh       connections, PTY shells, host key trust
   DodoSSH.Client.Terminal  the loopback data plane and credit-based flow control
   DodoSSH.Client.App       Avalonia; the only project that knows about a UI toolkit
@@ -104,11 +105,18 @@ off-Windows.
   *Server done:* the DSH1 crypto core, the data model, sync push/pull for hosts, `/me`, and
   enrollment with the identity-provider key binding.
   *Client done:* the key hierarchy, the OIDC flow with the key binding, SSH connections with host key
-  trust, the terminal data plane, an Avalonia shell whose terminal works end to end against a real
-  `sshd`, and the encrypted local cache with the sync client — hosts, offline unlock, an outbox and a
-  field-level three-way merge, with the conflict matrix green.
-  *Remaining:* wiring the shell to the vault, so the host list comes from `HostRepository` rather than
-  from the form the window still shows.
+  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.
+  *Remaining:* the manual end-to-end run against the real API and a real Keycloak from
+  `deploy/docker-compose.dev.yml`, which is what M1's definition of done actually asks for.
+
+  Known gaps in the client, stated rather than implied by the interface: credentials are not a synced
+  entity type yet, so a connection still asks for a password; known host keys live in memory for one
+  session instead of in the vault; and no device key is registered, so the passphrase is needed on every
+  launch until the OS keystore is wired.
 - **M2 — full personal vault**, robust sync, relay.
 - **M3 — teams**, sharing, ACLs.
 - **M4 — hardening and ops**, packaging, self-hosting guide.