Ask before deleting, and connect a host by double-clicking it

DELETE on a host, an SSH key, a stored password or a file on the host now puts
a question where the button was, and only answering it deletes anything. It is
a state rather than a dialog, which is the arrangement signing out already had
and for the same reason: this is the moment that has to be able to say what is
about to go before it goes.

What the question says is counted rather than generic, because a confirmation
that only asks whether you are sure is a click to train people out of. A key
names the hosts that authenticate with it and says they will refuse to connect
afterwards rather than falling back to a typed password, which is what the
connect path actually does. A host discloses a terminal open on it, because
deleting the host does not close the session. Every vault deletion says how far
it travels and whether this machine can push the tombstone yet or is queuing
it. Deleting on the host carries the strongest warning of the four on purpose:
everything else here is a tombstone against a copy the server still holds, and
a file on somebody's machine is bytes with nothing behind them — so that one
names the full path, since a bare name identifies nothing.

The armed request carries the item's entity id, so nothing that moves the
selection between the question and the answer can redirect it, and answering
about something that has since gone says so instead of doing nothing quietly.
Disarming compares ids rather than rows, which is the subtle half: a reload
replaces every row object, so the naive rule would have let the pass that runs
every minute take the card away from somebody halfway through reading it.

Forgetting a pinned host key is deliberately still unguarded. It costs one
fingerprint check on the next connection and it is the safe direction to be
wrong in — the dangerous button there is the one that adds trust, and that one
is already a prompt at connect time. Discarding a stopped transfer is likewise
unguarded: it removes a resumable part file and leaves the source alone.

Double-clicking a host in the sidebar connects to it, wired as a gesture in the
control exactly as the transfers screen opens a directory. CONNECT stays, since
it is the button with the password box beside it.

Ten existing delete call sites now go through arm-and-confirm helpers, and
eight new flow tests cover asking first, cancelling, the counted warning,
disarming on a selection change and on an editor opening, surviving a sync, and
the stale-item guard. Three layout tests measure the new shapes — the sidebar
card is the one card in the application a user cannot scroll — and one of them
also asserts the card renders its text, because a card whose compiled bindings
did not resolve would lay out perfectly as empty rows. The double-click test
performs the real gesture and proves it reached the connect command through a
refusal that never touches a network.

dotnet build, dotnet test and dotnet format --verify-no-changes are all clean:
853 tests, including the end-to-end suite against real containers.

src/DodoSSH.Client.App/Views/VaultScreen.axaml

@@ -1,6 +1,7 @@
 <UserControl xmlns="https://github.com/avaloniaui"
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
              xmlns:vm="using:DodoSSH.Client.App.ViewModels"
+             xmlns:views="using:DodoSSH.Client.App.Views"
              x:Class="DodoSSH.Client.App.Views.VaultScreen"
              x:DataType="vm:VaultViewModel">
 
@@ -220,11 +221,23 @@
                        Text="Vault items record no author, no timestamps and no sharing yet, so there is nothing more to show here." />
 
             <StackPanel Orientation="Horizontal" Spacing="6" Margin="0,14,0,0"
-                        IsVisible="{Binding SelectedItemIsEditable}">
+                        IsVisible="{Binding ShowsItemActions}">
               <Button Classes="ghost" Content="EDIT" Command="{Binding EditSelectedItemCommand}" />
               <Button Classes="danger" Content="DELETE" Command="{Binding DeleteSelectedItemCommand}" />
             </StackPanel>
 
+            <!--
+              The question DELETE asks, in the place those two buttons were. Here rather than over the
+              screen, because this pane is where the item being deleted is described: the name, the kind and
+              what is stored are all still on screen above it, which is most of what somebody checks before
+              answering. See ConfirmDeleteCard.
+            -->
+            <Border Background="{StaticResource DangerWash}" BorderBrush="{StaticResource DangerSoft}"
+                    BorderThickness="1" CornerRadius="4" Padding="10" Margin="0,14,0,0"
+                    IsVisible="{Binding IsConfirmingDeletion}">
+              <views:ConfirmDeleteCard />
+            </Border>
+
             <!--
               A pin has no editor and no Add, which is the one asymmetry on this screen and is deliberate:
               a pin appears because somebody approved a fingerprint at the moment of connecting, which is