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.

docs/manual-checks.md

@@ -74,10 +74,13 @@ pointer input matches a real mouse rather than a first look.
 
 Press Ctrl+K from the FILES screen and connect to a host whose key is not yet approved.
 
-**Pass:** the window lands on HOSTS with the fingerprint prompt visible and answerable.
+**Pass:** the fingerprint card comes up over the FILES screen, visible and answerable, and the screen
+underneath does not move — the transfer that was on it is still there when the question is answered.
+Approving connects; CANCEL leaves you on FILES.
 
 **Failure means:** the prompt is behind the screen that asked for it, and the connection is blocked on a
-question that cannot be reached.
+question that cannot be reached — or the window has jumped to HOSTS, which is what it used to do and what
+cost the palette its whole point.
 
 ### 1.6 The vault menu draws above the terminal's rectangle · **the one with a precedent**
 
@@ -814,8 +817,32 @@ would look.
 
 Connect to a host whose key is not yet approved.
 
-**Pass:** no tab is left behind, and the window is on HOSTS with the fingerprint prompt. Approving it
-connects and gives the tab a pane. This is 1.5 with the tab rework underneath it.
+**Pass:** no tab is left behind, and the fingerprint card is over whatever the window was showing. Approving
+it connects and gives the new tab a pane. This is 1.5 with the tab rework underneath it.
+
+### 7.4a A second connection's question, over a terminal that is open · **the occlusion one**
+
+With one terminal open and showing, connect to a *different* host whose key is not yet approved.
+
+**Pass:** the card is fully drawn and both its buttons take clicks. The terminal's rectangle is given up while
+it is up — the WebView is a native child window, so a card merely layered over it would be sliced at its left
+edge with TRUST AND CONNECT unreachable. Answering either way brings the pane back.
+
+**Failure means:** `IsTerminalShowing` has stopped asking `IsHostKeyDecisionShowing`, and the most
+safety-critical question in the product is half-drawn and unanswerable. No test can see this — headless
+Avalonia has no native child window.
+
+### 7.4b A changed host key can be got out of
+
+Connect to a host whose pin no longer matches (approve a key, then change it on the remote).
+
+**Pass:** the refusal is over the window with **no** way to continue — no "connect anyway", nothing that
+dismisses into a connection — and one control that puts it away. Pressing it leaves the screen that was
+underneath, and from there the host's editor and FORGET HOST KEY are reachable.
+
+**Failure means:** the refusal is stuck on screen. It was, until `RejectHostKey` started clearing the
+mismatch as well as the pending key: on the phone that left an opaque full-screen panel over every screen the
+user went to next, including the editor it tells them to open.
 
 ### 7.5 Giving up on a connection, and what arrives afterwards
 
@@ -1455,6 +1482,18 @@ colour, with no tab and nothing dialled.
 **Failure means:** for the suggestion strip, the box lost `Classes="secret"` — see 10.1, and it is the same
 seriousness here, since this password is typed rather than stored and so is typed often.
 
+### 11.7a A hand-typed machine's host key is judged on this screen · **the one the old arrangement got wrong**
+
+From Connections with nothing open, type a machine this keychain has never reached and press CONNECT.
+
+**Pass:** the UNKNOWN HOST KEY sheet rises **over this screen**. TRUST AND CONNECT opens the shell; CANCEL
+lowers the sheet and the box is still there, with what was typed still in it.
+
+**Failure means:** if the window is on HOSTS instead, the shell is navigating there before letting the
+handshake ask — which is what it used to do, and it is at its worst precisely here: a machine reached from
+this box is deliberately in no keychain, so it was being judged on a list it does not appear on, with the box
+that dialled it taken away. See `MainWindowViewModel.OnVaultConnectionFailed`.
+
 ### 11.8 A recent machine leads to the right place
 
 With at least one keychain host and one machine connected to by hand in the log, open Connections with