Add the Avalonia app and the xterm renderer, and fix two real bugs

The terminal works end to end. A new integration test drives a real sshd in
a container through a real PTY, the real pump, the real loopback WebSocket
with its token and origin checks, and a ClientWebSocket standing in for the
page: the login banner arrives, typed input round-trips, and `stty size`
reports the 100x30 the session asked for. The only untested link left is
xterm drawing bytes it was handed.

The WebView is de-risked on Windows, which was the plan's largest risk. Not
by assertion: with the app running there is an established TCP connection
from msedgewebview2 to the data plane port, so WebView2 launched, navigated
to the loopback page, executed terminal.js, and completed the WebSocket
handshake against the real token and origin checks. Linux remains unproven
and the package's own release notes now corroborate the concern -- Linux uses
a WPE backend, and it ships a NativeWebDialog described as useful where
embedded WebViews may be unavailable.

Two bugs found by building it, both of which would have shipped:

- ShellStream.Write buffers and needs an explicit Flush. Without one a
  keystroke is accepted, reported as written, and never reaches the remote:
  the terminal displays output perfectly and simply stops responding to
  input. SSH.NET's own WriteLine flushes, which is why the earlier spike
  never hit it. Found by isolating the pump against real SSH and reading
  BytesRead=51 -- banner and prompt through, nothing after.
- The Windows app manifest needs a supportedOS list, or Avalonia's native
  control host fails outright and the terminal never starts.

Also fixed a genuinely flaky test I happened to catch: SyncCursorTests
tampered with the *last* base64url character, whose low bits the decoder
ignores when the input length is not a multiple of three -- so a tampered
cursor sometimes decoded to identical bytes and verified. It failed roughly
one run in thirty, depending on a random key. Now tampers the penultimate
character, which is fully significant at every length; 40 consecutive runs
are clean.

xterm 6.0.0 plus the fit and webgl addons are vendored as UMD bundles rather
than built with npm, so a clean clone needs only the .NET SDK. Provenance
and licences are recorded next to them, along with the UMD global names
terminal.js depends on -- a bundle that switched to ES modules would load
without error and leave Terminal undefined.

The renderer acknowledges output from term.write's completion callback, not
on receipt. Acknowledging early would return flow-control credit for bytes
the screen has not caught up with, which is the one thing the credit window
exists to measure.

TerminalWorkspace moved into DodoSSH.Client.Terminal: it has no Avalonia
dependency, and having it there is what let the end-to-end test exist at all.

404 tests pass, zero warnings on a clean rebuild, format clean.

README.md

@@ -40,15 +40,23 @@ The reasoning behind each major decision is recorded in [`docs/adr/`](docs/adr/)
 
 ```
 src/
-  DodoSSH.Contracts       DTOs shared with the client — the real API contract
-  DodoSSH.Crypto          DSH1 envelope, AAD derivation, key wrapping
-  DodoSSH.Domain          entities and invariants, no EF
-  DodoSSH.Infrastructure  DbContext, configurations, migrations
-  DodoSSH.Api             the host
-tests/                    one test project per source project
-docs/adr/                 architecture decision records
+  DodoSSH.Contracts        DTOs shared with the client — the real API contract
+  DodoSSH.Crypto           DSH1 envelope, AAD derivation, the key hierarchy
+  DodoSSH.Domain           entities and invariants, no EF
+  DodoSSH.Infrastructure   DbContext, configurations, migrations
+  DodoSSH.Api              the server
+  DodoSSH.Client.Auth      OIDC code+PKCE on a loopback redirect, and the key binding
+  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
+tests/                     one test project per source project
+docs/adr/                  architecture decision records
 ```
 
+Everything under `src/DodoSSH.Client.*` except `App` is deliberately free of Avalonia. That is the
+seam that lets the SSH layer, the terminal's flow control and the OIDC flow be tested without a UI
+toolkit or a browser engine — which is most of why they are testable at all.
+
 ## Building
 
 Requires the .NET SDK pinned in [`global.json`](global.json) (10.0.x).
@@ -89,10 +97,13 @@ off-Windows.
 
 - **M0 — foundation.** Repo structure, build conventions, CI, ADRs. *Done.*
 - **M1 — vertical slice.** OIDC login → enroll → create a host → open a shell.
-  *Backend done:* the DSH1 crypto core, the data model, sync push/pull for hosts, `/me`, and
-  enrollment with the identity-provider key binding. *Remaining:* the desktop client, and the two
-  spikes that gate it — the Linux WebView and SSH.NET's `window-change`. Both need a Linux and a
-  macOS machine, so neither has run yet.
+  *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, and an Avalonia shell whose terminal works end to end against a real
+  `sshd`.
+  *Remaining:* the encrypted local cache and the sync client, which are what let the app read hosts
+  from the vault instead of a form. The client currently connects to a host you type in.
 - **M2 — full personal vault**, robust sync, relay.
 - **M3 — teams**, sharing, ACLs.
 - **M4 — hardening and ops**, packaging, self-hosting guide.