Ask about a host key where the connection was made, not on the host list

The trust prompt was two banners at the top of the desktop's hosts screen, so the shell navigated there
before letting a handshake raise one: Screen = Hosts, Surface = Page, in OnVaultConnectionFailed and again in
the palette's own connect. The reason was sound — a connection can be started from Ctrl+K on any screen, and
a question behind whatever somebody is looking at is a question nobody can answer — and it was answered the
wrong way round. Rather than making the decision reachable from where the user is, it moved the user to where
the decision was, and charged every screen for it.

It is worst for the one connection that has no host at all. A machine typed into the phone's connect box is
deliberately in no keychain, so a first contact from there judged it on a list it does not appear on, after
taking the box that dialled it away.

So both heads now draw the decision over the surface. HostKeyCard is the desktop's, and is the counterpart of
the phone's HostKeySheet: a scrim with no press handler, because a question with two named answers must not be
answerable by missing; the unknown key offering TRUST AND CONNECT, because judging a fingerprint against what
an operator published is a decision a person is entitled to make and the only moment they can make it; and the
changed key offering no way forward at all, because a button beside that warning is "continue anyway" with two
clicks instead of one. The phone needed no new markup — its sheet was already a shell-level overlay, so
deleting the navigation is what puts it over the Connections screen.

IsHostKeyDecisionShowing is on the shell rather than on a screen because the answer decides an occlusion. A
second connection can be refused while a first one is open, so this card is routinely raised over a live
terminal, and that rectangle is a native child window: layered over it the card would be sliced at its left
edge with TRUST AND CONNECT taking no clicks, which for the most safety-critical question in the product is
the worst place for that class of bug to land. IsTerminalShowing gives the rectangle up instead.

The banners are gone rather than copied. One prompt in two markups is two copies of the most safety-critical
wording here, and the second is the one that goes stale.

TWO DEFECTS FOUND BEHIND IT.

VaultViewModel.RejectHostKey cleared only the pending key and never the mismatch, so the changed-key refusal
had no working exit. That was invisible for as long as it was a banner nothing was drawn over — nothing was
trapped, and the next attempt cleared it — and it was already live on the phone, where that refusal is an
opaque full-screen panel whose one button runs this command: pressing it left the panel up over every screen
the user went to next, including the host editor the panel tells them to open. TransfersViewModel.RejectHostKey
has always cleared both; the vault's was the outlier. Its button said BACK TO HOSTS, which was wrong twice
over, and now says BACK.

And an assertion written for this change could not fail: the palette test asserted the renderer was collapsed
in a scenario whose only tab had just been removed, so it was collapsed for want of a session whatever the
occlusion rule said. It is gone, with a note pointing at the test that can fail on it.

VERIFIED. 1580 tests, build clean, no new warnings, format clean. Three mutations each seen to fail and then
seen green again: dropping !IsHostKeyDecisionShowing from IsTerminalShowing, caught by
AChangedHostKey_CollapsesTheTerminalItIsRefusedOver; reverting RejectHostKey to clear one flag, caught by
RefusingAHostKeyDecision_TakesItOffTheScreen(false) and by that same test; and dropping the two host-key arms
from OnVaultPropertyChanged, caught by TheHostKeyDecision_IsAnnouncedToTheWindowWhenItArrivesAndWhenItGoes.

That last one is the first test in this repository to watch PropertyChanged, and it is worth being the first:
every other assertion about the flag reads it directly, and a direct read passes with the subscription
deleted — while the card would never go away.

The two layout tests moved with the prompts, from the hosts screen to the card. manual-checks gains 7.4a for
the occlusion, 7.4b for getting out of a refusal and 11.7a for the hand-typed case, none of which a test can
see; 1.5 and 7.4 are corrected rather than left describing a window that no longer moves.

ONE ROUGH EDGE, DELIBERATELY LEFT. On the desktop, refusing a first contact whose tab was the only one leaves
the terminal surface with no tabs — a blank rectangle under the strip's "no terminals open · press + or
Ctrl+K", which is the one sentence near that rectangle Avalonia can draw. The alternative was falling back to
the page, and on the phone that means the host list, which is the bug this commit is about. A desktop connect
page would close it properly.

src/DodoSSH.Client.Android/Views/HostKeySheet.axaml

@@ -17,6 +17,13 @@
     and the plan names presenting it as dismissible as the one design mistake that matters here. A phone
     makes this easy to get wrong, because a bottom sheet is swipe-to-dismiss by convention; this is not a
     sheet for that reason, it is a full-screen panel.
+
+    ◆ WHAT IS BEHIND IT IS NO LONGER ALWAYS THE HOST LIST. The shell used to move to HOSTS before letting a
+    handshake ask this, because the desktop head drew the question as a banner on that screen; both heads draw
+    it over the surface now, so this is raised over whatever the user was on — including the connect box on the
+    Connections surface, which is where a machine that is in no keychain at all is dialled from. Nothing here
+    changes for that, and that is the point: this control never knew which screen it was over. See
+    MainWindowViewModel.OnVaultConnectionFailed and HostKeyCard.axaml on the desktop.
   -->
 
   <Panel>
@@ -107,8 +114,15 @@
           <!--
             The only control on the screen, and it goes back rather than forward. Compare the sheet above,
             where the accent button connects.
+
+            ◆ IT SAID "BACK TO HOSTS", AND IT NEITHER WENT THERE NOR CAME BACK. Two things were wrong with
+            it at once. RejectHostKey cleared only the pending key, so pressing it left HasHostKeyMismatch
+            set and this opaque panel up over whatever the user navigated to next — including the host editor
+            the paragraph above sends them to. And the shell no longer moves to Hosts to ask the question, so
+            even fixed it does not land there: it lowers this panel and reveals the screen that was already
+            underneath. "BACK" is what that is. See VaultViewModel.RejectHostKey.
           -->
-          <Button Classes="secondary" Content="BACK TO HOSTS" Margin="0,24,0,0"
+          <Button Classes="secondary" Content="BACK" Margin="0,24,0,0"
                   Command="{Binding RejectHostKeyCommand}" />
 
         </StackPanel>

src/DodoSSH.Client.Android/Views/PhoneShell.axaml

@@ -256,6 +256,12 @@
         ◆ The two host-key decisions, over everything. Outside the screen Panel deliberately: file transfer
         makes its own trust decision on the desktop, and the phone now has that screen — so a sheet nested
         inside the hosts screen would be one the files screen could not raise.
+
+        ◆ And that arrangement is what the shell now relies on rather than merely permits. It used to move to
+        HOSTS before letting a handshake ask the question, because the desktop head drew it as a banner on that
+        screen; it does not any more, so this sheet is what is over the Connections surface when a machine
+        typed into the connect box by hand turns out to be a first contact. Which is the case the navigation
+        was worst for — it took the box away. See MainWindowViewModel.OnVaultConnectionFailed.
       -->
       <Panel Grid.Row="1">
         <views:HostKeySheet DataContext="{Binding Vault}" />