Reconnect the terminal view when somebody comes back to it

Going back to a terminal left alone for a while found it stuck on
"Reconnecting the terminal view…", and stuck is the right word: the banner
stayed and nothing behind it was reconnecting.

The page's whole recovery story was a setTimeout chain, and a chain is exactly
what a WebView is entitled to stop running. Chromium throttles timers in a page
nobody is looking at — down to once a minute once it has been hidden five
minutes — and a renderer that is frozen, or reclaimed and not yet reloaded,
runs none of them. So the socket drops while nobody is watching, the banner
goes up, the retry is scheduled, and the retry is then the one thing not
running.

Three defects, each of which leaves that banner up for the rest of the page's
life.

◆ NOTHING LISTENED FOR THE PAGE COMING BACK. The only thing that could clear
the banner was a timer that may never fire. terminal.js now reconnects on
visibilitychange, focus and online — the events that mean somebody is looking
again, and the ones that cannot be throttled — cancelling the pending timer and
resetting the backoff. Over a healthy socket all three do nothing, which is
what makes them safe to fire as often as clicking a window does.

◆ A HANDSHAKE THAT NEVER FINISHED WAS INVISIBLE. Every retry was scheduled by a
close or an error, so an attempt parked in CONNECTING — which is what a
suspended renderer leaves behind — scheduled nothing at all, ever. There is now
a five-second watchdog on the handshake.

◆ STALE SOCKETS SCHEDULED RETRIES, AND THAT ONE IS A LOOP RATHER THAN A STALL.
connect() never detached the old socket's handlers, and the host aborts the
displaced socket on takeover — TerminalDataPlane.UpgradeAsync, doing exactly
what it should. That close read as a fresh failure and scheduled a retry
against the socket that had just succeeded, whose own close scheduled the next:
no fixed point, reconnecting every second forever with the banner up for most
of it. Every handler now asks whether it is still the page's own attempt, and
connect() closes what it abandons.

◆ WHICH OF THE PLATFORM BEHAVIOURS ACTUALLY BIT IS NOT ESTABLISHED, and the fix
does not depend on knowing. Throttled timers, a frozen renderer and a reclaimed
one all end at the same dead timer; guessing between them would have produced a
narrower fix for one of the three.

THE TEST RUNS terminal.js ITSELF, in a fake browser, inside dotnet test.
RendererPage loads the file the shell project ships — not a transcription of its
logic into C#, which would be a copy that stays correct while the page rots —
into a Jint engine, one per test, over a harness that fakes a WebSocket and a
clock and nothing else. Jint rather than a node script because CI would run the
node one and nobody's inner loop would; the cost is that Jint is not Chromium,
so this proves the page's logic and nothing about how a WebView behaves. That
line is drawn in RendererPage's remark and picked up by two new manual checks,
1.10 for the desktop and 11.12a for the phone, which own the platform half.

Four of the nine tests fail against the page as it stood — the stale close, the
parked handshake, and the two wake-ups. Two more assert that a wake-up over a
healthy socket does nothing, and pass against either version on purpose: they
are what stops the cure being worse.

Left alone deliberately: a socket that is open and dead shows no banner at all,
because readyState still reads OPEN. That looks like a terminal that swallows
what is typed, needs a liveness probe rather than a faster retry, and is written
down at the end of 11.12a rather than quietly bundled in here.

tests/DodoSSH.Client.Terminal.Tests/DodoSSH.Client.Terminal.Tests.csproj

@@ -4,10 +4,44 @@
     The throughput and backpressure harness the plan requires before any UI exists. Nothing
     here needs a WebView: the flow control is what is most likely to be wrong, and it is pure
     logic once ITerminalTransport is a seam.
+
+    And, since RendererReconnectionTests, the renderer's own half of the same protocol — the page
+    that reads these frames, run as a script rather than described in C#. It lives here rather than
+    in a test project of the shell's own because this is where the other end of the socket is
+    tested, and the two halves of "the renderer stays attached" are one mechanism: the host takes
+    a second upgrade over the first, and the page is what makes that second upgrade happen. A
+    project for the shell would still need a reference to this one's subject to say anything.
   -->
 
   <ItemGroup>
     <ProjectReference Include="../../src/DodoSSH.Client.Terminal/DodoSSH.Client.Terminal.csproj" />
   </ItemGroup>
 
+  <ItemGroup>
+    <!--
+      A JavaScript engine, so terminal.js can be run as it ships instead of transcribed into C#.
+      See RendererPage for the trade against a node script, and for what an engine that is not
+      Chromium can and cannot prove.
+    -->
+    <PackageReference Include="Jint" />
+  </ItemGroup>
+
+  <ItemGroup>
+    <!--
+      ◆ THE PAGE IS COPIED OUT OF THE SHELL PROJECT, WHICH IS THE ONE ODD THING IN THIS FILE.
+
+      Reaching across for a source file is not something else here does, and the alternatives are
+      worse: referencing DodoSSH.Client.Shell would drag Avalonia into a suite that draws nothing,
+      and a copy of the page checked in beside the tests would be a copy — the thing that quietly
+      stops matching what ships, which is precisely the failure this test exists to catch.
+
+      PreserveNewest rather than Always so that editing the page is what rebuilds it.
+    -->
+    <None Include="../../src/DodoSSH.Client.Shell/WebAssets/terminal.js"
+          Link="Renderer/terminal.js"
+          CopyToOutputDirectory="PreserveNewest" />
+
+    <None Include="Renderer/renderer-harness.js" CopyToOutputDirectory="PreserveNewest" />
+  </ItemGroup>
+
 </Project>