Merge branch 'main' into the vaults screen, and let it rotate keys too

Main built vault key rotation while this branch was reshaping the screen that
would drive it, so the two met in the same three files. Every other conflict was
textual and resolved by taking both; these are the ones where a decision had to
be made.

**The view model.** Main taught TeamsViewModel three things and this branch had
renamed and rewritten it into VaultsViewModel. All three are ported rather than
dropped, because each is a behaviour rather than wording: adding somebody now
wraps the vault to them on the spot instead of leaving SHARE KEY to be pressed,
removing somebody rotates the vault and hands the new key to whoever is left, and
a share reports how many generations were wrapped. The session calls they reach —
ShareTeamVaultsAsync and RekeyTeamVaultsAsync — are scoped to a membership list
rather than to one vault, and they are called that way here rather than narrowed:
adding somebody is a change to the list, so every vault the list carries is one
they can now fetch. This screen makes lists that carry one vault, so the sentences
name one; where a list carries several, naming them all is the honest report, and
the members section already says the list is shared.

AddMemberAsync ran two lines over the length limit once the sharing was in it, so
the calls behind it moved to AddOrInviteAsync and the three-way refusal to
WhyNobodyCanBeAdded — the command reads as its guards now, which is what it was
before the sharing arrived.

**The tests.** Main's four new cases are ported to the vault-first API, including
the one that matters most: the tampered key log is corrupted *before* the add,
because the add is now a route to a wrap and a test that corrupted it afterwards
would be asserting about the manual route only. SelectingAVault_ListsWhoHoldsAKey
now expects two holders rather than one — main's fake records the creator's own
self-grant, and a key-holder list that omitted it would show the one person who
can certainly open a new vault as somebody who cannot.

**The README.** The limits list is six rather than four or five: main's rotation
entries and this branch's "a vault cannot be deleted" describe different things
and both are true. "The rekey is flagged, never performed" is gone, since it is
now performed, and M3 reads *Done* rather than *Done, except rekey*.

One thing worth writing down that neither side had. An invitation claimed at
sign-in still leaves the key owed, where an add does not: at the moment an
invitation is issued there is no account and no published key to wrap to, and the
claim happens on the invitee's machine, which holds nothing. Manual check 12.1
says so, because a reader who knows adding shares would otherwise read that step
as stale.

1561 tests pass.

src/DodoSSH.Contracts/Teams.cs

@@ -425,6 +425,37 @@ public sealed record IssueVaultGrantRequest(
     byte[] GrantSignature,
     DateTimeOffset GrantedAt);
 
+/// <summary>
+/// Moves a vault to a fresh key, wrapped to the caller.
+/// </summary>
+/// <remarks>
+/// <para>
+/// The new key is generated by a client that already holds the current one, and arrives sealed to that
+/// same client — the server can neither produce it nor tell that it differs from the old one. What the
+/// server does is decide the moment it takes effect: the generation advances in one transaction, so
+/// there is no instant at which two clients disagree about which generation is current.
+/// </para>
+/// <para>
+/// <b>Grants for earlier generations are kept, not revoked.</b> Every item still carries the generation
+/// it was sealed under, so withdrawing them would make the vault's whole history unreadable to the
+/// people who are still in it. The departed member's grants are revoked — that is what
+/// <c>RevokeGrantAsync</c> and removal from the team already do — and this is what stops them reading
+/// anything written from here on. It does not reach back; see ADR 0001.
+/// </para>
+/// </remarks>
+/// <param name="KeyGeneration">
+/// The generation being created. Must be exactly one past the vault's current one, so two clients
+/// rotating at once cannot both believe they succeeded.
+/// </param>
+/// <param name="WrappedVaultKey">The new vault key, sealed to the caller's own encryption key.</param>
+/// <param name="GrantSignature">Ed25519 signature over the canonical grant tuple.</param>
+/// <param name="GrantedAt">Signing timestamp, part of the signed tuple.</param>
+public sealed record RekeyVaultRequest(
+    uint KeyGeneration,
+    byte[] WrappedVaultKey,
+    byte[] GrantSignature,
+    DateTimeOffset GrantedAt);
+
 /// <summary>One vault key grant, as the sharing interface sees it.</summary>
 /// <remarks>
 /// The wrapped key itself is deliberately not here. A member reads their own through
@@ -457,7 +488,12 @@ public sealed record VaultGrantSummary(
 /// compares against rather than inferring from <see cref="VaultGrantSummary.State"/> alone.
 /// </param>
 /// <param name="RekeyRequired">Whether a membership change has left this vault needing a rekey.</param>
-/// <param name="Grants">Every grant, including revoked ones.</param>
+/// <param name="Grants">
+/// One row per holder, including those whose access has been withdrawn. Not one per grant: a rotated
+/// vault leaves a member holding one grant per generation, and the row carries the best of them — so
+/// <see cref="VaultGrantSummary.KeyGeneration"/> below <paramref name="KeyGeneration"/> means they have
+/// not been wrapped the current key yet, rather than that one of their grants is old.
+/// </param>
 public sealed record VaultGrantsResponse(
     Guid VaultId,
     uint KeyGeneration,