Let a host be moved to another vault

The one thing the host editor's vault picker has always been unable to offer,
and the comment beside it said so: an existing host's vault was not a field
because the two vaults are encrypted under different keys. That is still true.
What changed is that it is no longer a reason to have nothing.

**A move is a copy and a tombstone, and it cannot be anything else.** A payload
is sealed under its vault's key and its AAD binds the vault, the entity id and
the item version, so no edit moves one and no server call could — the server
holds ciphertext it cannot read. What crosses is the plaintext, in this process,
between an unwrap under one key and a seal under another. VaultItemRepository
gained MoveAsync for it, so the three decisions below live in one place with
their reasons rather than being re-derived at each call site.

The item takes a new id. Keeping it would put one entity id in two vaults, and
the item table is keyed on the type and the id rather than on the vault — so the
destination's row and the source's tombstone would be the same row, and the move
would delete what it had just written.

The write comes first and the tombstone second, which decides what an
interruption leaves: a copy in both vaults, visible and deletable, rather than a
tombstone with nothing on the other side. Both are queued rather than sent, so
the window is a crash between two local writes; it is still worth being on the
survivable side of.

Two activity lines rather than one, because that is what the two vaults actually
record. A single "moved" line would have to be written to one of them and would
be missing from the other's history.

**The group and the tags stay behind, and that is the half that makes this
honest.** Both are items of the vault the host is leaving: the editor's group
picker offers one vault's groups and the chips are drawn from one vault's tags.
A host carrying either across would resolve it on the machine that moved it —
groups and tags are resolved over every readable vault — and dangle for everybody
else in the destination. The mover and their colleagues would be looking at two
different hosts. Cleared and reported beats carried and invisible.

The key or password binding is kept, and the difference is not inconsistency.
Those genuinely resolve across vaults — one key on twenty hosts in three vaults
is the arrangement they exist for — so clearing them would take a working host
and make one that cannot connect. What the message does instead is name a
binding that is now outside the destination, because that is precisely what the
other members of it will not be able to resolve.

**It is not in the editor**, on either head: the desktop puts it in the detail
pane's ⋯ menu above the separator Delete sits below, and the phone beside EDIT.
A picker inside the form would move a machine as a side effect of correcting a
port, which is the bug the editor's own vault picker was fenced off to prevent in
the first place. The panel takes the footer as the deletion question does, and
says what will be left behind before the tap rather than after it — on a phone,
where the status line afterwards is one line on a screen somebody has already
navigated away from, that is the only place it reliably gets read.

The phone hides the button where there is nowhere to go rather than offering one
that answers with a refusal; the desktop keeps its menu entry either way, because
a menu that grew and shrank would be a menu whose items move.

One thing found while writing the test and deliberately not changed. The pass
that follows every write on this screen reports what it moved and supersedes the
confirmation — for a save and a delete as much as for a move — so the move's own
sentence is what somebody sees offline. The test asserts it in that state and
says why. Making confirmations survive their own sync pass is a question about
the whole screen rather than about this.

Four places said an item could never be moved, two of them sentences on screen in
both heads. All four now say what is true, including the design gaps document,
where the chevron beside the vault name stays undrawn for a different reason: a
chevron on a subtitle implies an edit, and this is a re-seal, a new id and two
references left behind.

src/DodoSSH.Client.Sync/HostRepository.cs

@@ -38,6 +38,15 @@ public sealed class HostRepository(
         CancellationToken cancellationToken) =>
         hosts.UpdateAsync(vaultId, entityId, host, cancellationToken);
 
+    /// <inheritdoc cref="VaultItemRepository{TSecret}.MoveAsync" />
+    public Task<Guid> MoveAsync(
+        Guid fromVaultId,
+        Guid toVaultId,
+        Guid entityId,
+        HostSecret host,
+        CancellationToken cancellationToken) =>
+        hosts.MoveAsync(fromVaultId, toVaultId, entityId, host, cancellationToken);
+
     /// <inheritdoc cref="VaultItemRepository{TSecret}.DeleteAsync" />
     public Task DeleteAsync(Guid vaultId, Guid entityId, CancellationToken cancellationToken) =>
         hosts.DeleteAsync(vaultId, entityId, cancellationToken);

src/DodoSSH.Client.Sync/VaultItemRepository.cs

@@ -234,6 +234,72 @@ internal sealed class VaultItemRepository<TSecret>(
         }
     }
 
+    /// <summary>
+    /// Moves an item into another vault.
+    /// </summary>
+    /// <param name="fromVaultId">The vault it is in.</param>
+    /// <param name="toVaultId">The vault it should be in.</param>
+    /// <param name="entityId">The item.</param>
+    /// <param name="secret">
+    /// What to write into the destination. The caller's, rather than read from here, because moving is the
+    /// one operation where the item does not arrive unchanged: references to things that live in the vault
+    /// it is leaving are the mover's to resolve, and this layer has no way to know which those are.
+    /// </param>
+    /// <param name="cancellationToken">Cancellation token.</param>
+    /// <returns>The id the item has in its new vault.</returns>
+    /// <remarks>
+    /// <para>
+    /// <b>A copy and a tombstone, and it cannot be anything else.</b> An item's payload is sealed under
+    /// its vault's key and its AAD binds the vault, the entity id and the item version — so there is no
+    /// edit that moves one, and no server call that could: the server holds ciphertext it cannot read.
+    /// What crosses is the plaintext, in this process, between an unwrap under one key and a seal under
+    /// another.
+    /// </para>
+    /// <para>
+    /// <b>A new id, deliberately.</b> Keeping it would put one entity id in two vaults, and the item table
+    /// is keyed on the type and the id rather than on the vault — so the destination's row and the
+    /// source's tombstone would be the same row, and the move would delete what it had just written.
+    /// Callers holding the old id have to take the new one back.
+    /// </para>
+    /// <para>
+    /// <b>The write comes first and the tombstone second</b>, which decides what an interruption leaves
+    /// behind: a copy in both vaults, which is visible and can be deleted, rather than a tombstone with
+    /// nothing on the other side, which is the host gone. Both are queued rather than sent, so the window
+    /// is a crash between two local writes — narrow, and worth choosing the survivable side of anyway.
+    /// </para>
+    /// <para>
+    /// Two activity lines, not one: a create in the destination and a delete in the source, which is what
+    /// the vaults actually record. A single "moved" line would have to be written to one of them and would
+    /// be missing from the other's history.
+    /// </para>
+    /// </remarks>
+    internal async Task<Guid> MoveAsync(
+        Guid fromVaultId,
+        Guid toVaultId,
+        Guid entityId,
+        TSecret secret,
+        CancellationToken cancellationToken)
+    {
+        ArgumentNullException.ThrowIfNull(secret);
+
+        if (fromVaultId == toVaultId)
+        {
+            throw new ArgumentException(
+                "That item is already in that vault.", nameof(toVaultId));
+        }
+
+        // Both keys before either write, so a destination this session cannot write to is refused with
+        // nothing having happened rather than after the source item has gone.
+        _ = Key(fromVaultId);
+        _ = Key(toVaultId);
+
+        var moved = await CreateAsync(toVaultId, secret, cancellationToken).ConfigureAwait(false);
+
+        await DeleteAsync(fromVaultId, entityId, cancellationToken).ConfigureAwait(false);
+
+        return moved;
+    }
+
     /// <summary>
     /// Deletes an item.
     /// </summary>