Merge branch 'main' into claude/m3-implementation-57f9d7

Three files conflicted, and two of the resolutions are more than a choice of
side.

QuickConnectTests had both branches fixing the same build break — main's M2
merge left the shell's constructor with an ISftpSessionFactory nobody passed.
Main's version wins because it carries a comment saying why the palette never
needs a session.

VaultSession's conflict is adjacent edits: main added the remembered sign-in
members and this branch changed SyncAsync's summary from "the active vault" to
"one vault". Both kept.

VaultViewModel is the one that matters. Main taught the background pass to
report a sync that had to start over, on the grounds that a machine which
silently re-read a whole vault has had something happen to it; this branch
turned a pass into one report per readable vault. Taking either side alone
would have lost the other, so ResyncedFromStart is now one of the conditions
IsWorthReporting checks, per vault.

Merging also broke something neither branch could have caught alone, and the
build would not have said a word. SyncOnceAsync cleared LastSyncFailed
unconditionally, which was right while a pass was one vault and a failure was
an exception that never reached that line. A failure is now a report — one
unreachable team vault must not stop the others syncing — so the flag was being
cleared over a vault that had just failed, lighting the titlebar SYNCED. It is
computed from the report instead, in the one place both callers go through, so
the manual command gets it as well as the loop. The background pass still
swallows the message and keeps the fact, which is what
AnAutomaticPassThatFails_LeavesTheStatusAlone is there to hold it to.

Two comments the auto-merge left describing a world with one vault in it: the
SCOPES rail's, which said team vaults are refused by the access service, and
the host sidebar's "One heading, for one vault".

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">
 
@@ -17,9 +18,10 @@
     two headings that could never have anything under them. HOST KEYS is the other way round: a real,
     fully-backed category the design has no slot for. Both are recorded in docs/design-import-gaps.md.
 
-    The SCOPES rail below the categories is the vault list, which is real and today has one entry in it. The
-    design shows three, two of them teams; team vaults exist as tables on the server and are refused by its
-    access service, so a rail with three entries would be showing two vaults nothing can open.
+    The SCOPES rail below the categories is the vault list. Since M3 it genuinely has more than one entry
+    when somebody is in a team — but it is still not a selector, because every table on this screen already
+    spans every vault this session holds a key for and each row names its own. What it carries instead is
+    the one vault question with an answer: where a new item is filed.
   -->
 
   <Grid ColumnDefinitions="176,*,244">
@@ -237,11 +239,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