Add the SSH session layer and the terminal data plane

The throughput harness the plan requires before any UI, plus the SSH
plumbing under it. 94 new tests, no WebView involved.

Credit-based flow control is what makes `yes` survivable. A terminal renders
at 60 Hz at best while a remote produces output as fast as the network
allows, and the difference has to accumulate somewhere or be refused.
Credit is reserved *before* reading, never after: because the pump cannot
read more than the renderer has room for, the coalescing buffer is bounded
by the window rather than by how fast the remote can talk. When credit runs
out the pump stops reading, SSH's own receive window closes, and the remote
sshd blocks -- backpressure to the source with no custom protocol.

Verified by falsification, not just by passing: with the credit gate removed
three tests fail, including the throughput harness's bounded-memory
assertion. Acknowledgements are clamped because they cross into JavaScript,
where a buggy or hostile page could otherwise claim to have rendered a
gigabyte and talk the host into an unbounded read.

Host key trust is enforced by *failing* the connection rather than
prompting inside the handshake. SSH.NET raises verification synchronously,
so consulting the user there would block the handshake on a UI round trip
and deadlock the first time the prompt needed the UI thread. Unknown host
and changed key become distinct exceptions the caller resolves
asynchronously. A mismatch has no retry path at all: a dialog offering to
continue is how users are trained to click through the one warning that
actually indicates interception. A legitimately rebuilt server is handled by
removing the pin in settings, away from the moment of connecting.

The data plane serves the renderer page from the same loopback listener as
the socket, which makes Origin predictable -- always http://127.0.0.1:{port}
-- where a WebView virtual-host mapping would give a different origin per
backend and nothing to validate. The token is substituted at serve time, so
it never touches disk and never appears in a URL. Being clear about what
that buys: not protection from a process running as this user, which can
read our memory anyway, but from a page in the user's browser attempting
WebSocket connections to loopback ports, which is a real and routine thing.

Two bugs the tests caught. The accept loop handled connections serially, so
an upgraded WebSocket parked it inside the receive loop and every later
request went unanswered -- the page's own script among them. The suite hung
rather than failed, which is how I found it. And SHA-1 is unavoidable here:
RFC 6455 mandates it for Sec-WebSocket-Accept, where it authenticates
nothing. Suppressed narrowly with that reasoning; the alternative,
HttpListener.AcceptWebSocketAsync, throws PlatformNotSupportedException off
Windows.

src/DodoSSH.Client.Ssh/TerminalSize.cs

@@ -0,0 +1,35 @@
+using System.Runtime.InteropServices;
+
+namespace DodoSSH.Client.Ssh;
+
+/// <summary>
+/// A pseudo-terminal's dimensions.
+/// </summary>
+/// <remarks>
+/// Both the character grid and the pixel extent, because the SSH <c>pty-req</c> and
+/// <c>window-change</c> requests carry both. Pixel dimensions are what let a remote program draw
+/// sixel graphics or size an image correctly; sending zeroes is legal and tells the remote there is
+/// no pixel information, which is not the same as telling it the terminal is zero pixels wide.
+/// </remarks>
+/// <param name="Columns">Character columns.</param>
+/// <param name="Rows">Character rows.</param>
+/// <param name="PixelWidth">Width in pixels, or 0 when unknown.</param>
+/// <param name="PixelHeight">Height in pixels, or 0 when unknown.</param>
+[StructLayout(LayoutKind.Auto)]
+public readonly record struct TerminalSize(
+    ushort Columns,
+    ushort Rows,
+    ushort PixelWidth = 0,
+    ushort PixelHeight = 0)
+{
+    /// <summary>The conventional default, for a session opened before the UI has measured itself.</summary>
+    public static TerminalSize Default => new(80, 24);
+
+    /// <summary>Whether the size is usable as a terminal.</summary>
+    /// <remarks>
+    /// A zero dimension is worth rejecting rather than forwarding: a resize to 0×0 arrives naturally
+    /// when a pane is collapsed or a window minimised, and passing it on makes the remote's idea of
+    /// the terminal nonsensical until the next resize.
+    /// </remarks>
+    public bool IsUsable => Columns > 0 && Rows > 0;
+}