Make the vault the thing you share, and ask a host which one it lives in

The teams screen listed teams that owned vaults, so sharing four servers with two
colleagues meant creating a team, then a vault inside it, then wrapping a key.
Two of those three steps are about a concept nobody arrives wanting. The screen
now lists vaults: naming one creates the membership list that carries it, named
after the vault and owned by you, and members, invitations, roles, hand-over and
key holders all hang off the vault they apply to.

Nothing on the server moved. VaultAccessService still resolves a shared vault
through team_membership and every membership call still names a team id — what
went is the requirement that anybody make one. The split the whole design rests
on is untouched and is still what the screen is built around: adding somebody
authorises the server to serve them, and only a machine holding the key can make
the vault readable. ADR 0009 keeps its decision and gains an addendum recording
which half of it a person is now asked about.

The one place the team resurfaces is a membership list carrying several vaults,
which this screen cannot produce and does not hide: the members section says so,
because "adding somebody here adds them there" is precisely the fact a
vault-shaped screen is in a position to conceal.

Two things left the interface and one arrived. Creating a team is gone, and so is
archiving one — it was only ever possible for a team owning no vaults, and a
screen whose rows are vaults has no row for one, so the button would have been
unreachable or always refused. The endpoint is unchanged and the screen states
the limit instead, since a vault cannot be deleted at all. The exception is a
create whose second call failed: cancelling that form archives the membership
list it left behind, which is a deliberate departure from this client's rule
against tidying up on the user's behalf, made because nothing else can reach it.

What arrived is PUT /api/v1/vaults/{id}. Without it the screen loses its only
editing action, since renaming the team behind a vault is invisible to everybody
who was never shown the team. It is gated on PermissionFlags.Admin — the line
UpdateTeamEndpoint already draws, because a name is what everybody in the vault
sees it called rather than part of its contents — and it renames the owning team
with it when that team carries nothing else, so the row an operator reads and the
name a user says cannot drift apart. The slug never moves, for the reason it does
not move on a team rename. The session edits its cached vault row rather than
replacing it with the response, which deliberately carries no wrapped key.

The host editor now asks which vault a host goes into, beside the name, while
adding and only where there is more than one vault to write to. It is a second
picker rather than the keychain screen's reused, and the two selections are
separate on purpose: that one is a standing preference about where new items go,
this is a field of the host in front of you, and binding both to one selection
would mean a click on the other screen could move a half-typed host. An existing
host is not offered it at all rather than offered it disabled — the two vaults
are encrypted under different keys, so moving an item is a delete and a retype.

That forced a fix worth naming. The group picker was built from the active
vault's groups whatever vault the host was being filed into, so a host put in a
shared vault could be filed under a group only its author can resolve — a
colleague would see it filed under nothing, which is the quietest kind of wrong.
Groups are now kept per vault and the picker follows the vault choice.

Two renames, because the pair they would otherwise have made is a bug farm:
ShellScreen.Vault became Keychain and VaultScreen became KeychainScreen, which is
what the rail has always labelled that screen, leaving Vault for one vault's
contents and Vaults for the vaults themselves. The enum values are unchanged;
NavRail.axaml writes them as x:Static literals.

1536 tests pass, seven more than before. Five are new on the server — the rename
endpoint's success, the team it does and does not take with it, the two refusals
and the empty name — and the client suite gains six and folds four together,
having lost the two about archiving a team.

docs/manual-checks.md

@@ -28,7 +28,7 @@ a phase had nothing left for a person to do, which is the good outcome rather th
 
 ### 1.1 No screen is sliced at the WebView's left edge · **the important one**
 
-Open two terminals, then visit every nav rail entry in turn — Hosts, Keychain, Pins, Snippets, Logs, Teams,
+Open two terminals, then visit every nav rail entry in turn — Hosts, Keychain, Pins, Snippets, Logs, Vaults,
 Preferences — and both of the fixed tabs, SFTP and S3.
 
 **Pass:** each screen draws whole, its buttons all clickable, and the tab strip stays across the top of all
@@ -1130,7 +1130,7 @@ case, and those two have to move together — the switch mirrors that property b
 
 ---
 
-## Phase 12 — Teams: the operations that span two accounts
+## Phase 12 — Shared vaults: the operations that span two accounts
 
 The server's own rules are covered by the endpoint suite: teams are renamed, an archive is refused while a
 vault is in the way, ownership changes hands, and every branch of the invitation claim is driven with
@@ -1147,16 +1147,16 @@ follows is about what happens the first time it does.
 
 ### 12.1 An invitation becomes a membership at the invitee's first sign-in · **the one worth the most care**
 
-1. Sign in as `alice`, make a team, and open its invitations.
-2. Invite `bob@example.com` as a Member. **Nothing is sent, and nothing should look as though it was** —
+1. Sign in as `alice`, make a vault on the VAULTS screen, and select it.
+2. Add `bob@example.com` as a Member. **Nothing is sent, and nothing should look as though it was** —
    no "invitation emailed", no link to copy, no token anywhere on the screen.
 3. **Pass:** the row appears as *pending*, carrying the address, the role and an expiry fourteen days out.
    Bob is **not** in the members table, because he has no account here for a membership row to point at.
 4. Sign in as `bob` on the second profile and enroll.
-5. **Pass:** the team is in Bob's list the first time he looks, at Member, with nothing further pressed on
-   either side. Back on Alice's machine, refresh: the invitation reads *accepted* rather than vanishing,
+5. **Pass:** the vault is in Bob's list the first time he looks, at Member, with nothing further pressed
+   on either side. Back on Alice's machine, refresh: the invitation reads *accepted* rather than vanishing,
    and Bob is now in the members table.
-6. **Pass, and this is the half that is easiest to lose:** the team's vault is in Bob's list **saying it is
+6. **Pass, and this is the half that is easiest to lose:** the vault is in Bob's list **saying it is
    waiting for a key**, and nothing in it is readable. Have Alice press SHARE KEY and Bob sync; now it
    opens.
 
@@ -1171,15 +1171,15 @@ reached that machine by a route this architecture says does not exist.
 In Keycloak's admin console, clear **Email verified** on the invitee *before* their first DodoSSH sign-in.
 Invite that address, then sign in as them.
 
-**Pass:** they get an account and a personal vault and no team at all. The invitation stays *pending* on
+**Pass:** they get an account and a personal vault and no shared one. The invitation stays *pending* on
 the inviter's screen rather than turning into anything, and the API log carries a warning naming how many
 invitations it declined to claim. Now set **Email verified** back on. The claim happens on the next request
 that crosses the hourly last-seen window, so it is **not** immediate and restarting the client will not
 hurry it along — the account already exists, so there is no second first-sign-in to trigger it.
 
-**Failure means:** if the team appears while the address is unverified, the one security boundary
+**Failure means:** if the vault appears while the address is unverified, the one security boundary
 invitations have is not being enforced, and anybody able to obtain a token asserting a colleague's address
-can walk into their team. Stop there. If it stays pending after verifying, the claim is not reaching the
+can walk into their vault. Stop there. If it stays pending after verifying, the claim is not reaching the
 **access** token — check the provider's mappers, and set `Oidc:EmailVerifiedClaim` if it sends the claim
 under some other name.
 
@@ -1188,27 +1188,27 @@ under some other name.
 Invite an address, then revoke it before anybody has signed in with it. Then sign in with that address.
 
 **Pass:** the row reads *revoked* and stays on the list rather than disappearing, and the sign-in produces
-an ordinary account in no team. Revoking one that has *already* been accepted answers that there was
-nothing to withdraw.
+an ordinary account in no shared vault. Revoking one that has *already* been accepted answers that there
+was nothing to withdraw.
 
 **Failure means:** a revoked invitation that still lets somebody in is a removal that did not remove. An
 accepted one that could be unpicked here would be worse: it is a membership now, and removing a member
-revokes their vault key grants and flags every team vault for rekey, which is not what "revoke invitation"
+revokes their vault key grants and flags the vault for rekey, which is not what "revoke invitation"
 should quietly do.
 
 ### 12.4 An address already in the team is refused; an address that merely has an account is not
 
-With Bob in the team, invite `bob@example.com` to it again.
+With Bob in the vault, add `bob@example.com` to it again.
 
 **Pass:** refused, with a sentence saying the address already belongs to a member and to change their role
-instead. Now make a **second** team and invite the same address there.
+instead. Now make a **second** vault and invite the same address there.
 
 **Pass:** accepted. Bob having an account is deliberately not a reason to refuse — it is claimed within the
 hour on his next request rather than at a sign-in, so give it that long before deciding it has not worked.
 
 **Failure means:** if the second invitation is refused because the address already has an account, this
 endpoint has become a way of asking the server which addresses have accounts on it, answerable by anybody
-willing to create a team first. See ADR 0009.
+willing to create a vault first. See ADR 0009.
 
 ### 12.5 LAST ACTIVE is a real time, and a coarse one · **needs a couple of hours**
 
@@ -1227,49 +1227,53 @@ impossible to offer honestly before.
 
 As the owner, transfer ownership to another active member, then read both rows.
 
-**Pass:** they are Owner and you are **Admin** — not removed, not Member. Your vault key grants are intact
-and the team's vaults have not come back flagged for rekey. Then try to transfer to somebody who is not a
-member, and to yourself.
+**Pass:** they are Owner and you are **Admin** — not removed, not Member. Your vault key grant is intact
+and the vault has not come back flagged for rekey. Then try to hand it to somebody who is not a member, and
+to yourself.
 
 **Pass:** both refused, and the message says which.
 
 **Failure means:** two owners, or none, is the state this being a single transaction exists to prevent, and
-either one leaves a team that no client can administer back into shape. If your grants were revoked or the
-vaults are now flagged for rekey, the transfer is removing the outgoing owner rather than demoting them.
+either one leaves a vault that no client can administer back into shape. If your grant was revoked or the
+vault is now flagged for rekey, the transfer is removing the outgoing owner rather than demoting them.
 
-### 12.7 Archiving is refused while the team owns a vault
+### 12.7 A vault cannot be deleted, and the screen says so rather than offering a button
 
-With a team that owns at least one vault, try to archive it.
+Look for a way to remove a vault, on both heads.
 
-**Pass:** refused, and the message counts the vaults in the way and says there is no way to delete a vault
-in this product. The team is still in everybody's list afterwards and its vaults still open.
+**Pass:** there is none, and the VAULTS screen says why in a sentence: nothing in this product removes a
+vault, and the server refuses to archive the membership list behind one while it exists. Archiving that
+list is still reachable over the API, and the endpoint suite drives both its refusal and its success — what
+is being checked here is that no button offers it.
 
-**Failure means:** an archive that succeeded here would have taken those vaults out of the list of
-everybody holding a key — including the person who pressed it, quietly, and with nothing in the product
-able to put them back.
+**Failure means:** a delete that worked would take the vault out of the list of everybody holding a key —
+including the person who pressed it, quietly, and with nothing in the product able to put them back. A
+button that always refuses is the milder failure and is still worth removing.
 
-### 12.8 Archiving an empty team takes its memberships and its invitations with it · **needs two accounts**
+### 12.8 Renaming a vault reaches every place its name is drawn · **needs two accounts**
 
-Make a team that owns no vaults, add the second account to it, invite a third address, and archive it.
+Rename a shared vault from the VAULTS screen.
 
-**Pass:** the team is gone from both accounts' lists. Sign in with the invited address afterwards and it
-joins nothing. A new team can be created under the archived one's slug.
+**Pass:** the new name is on the vault list, on the badge of every host card in that vault, in the keychain
+screen's "new items go to" picker, in the host editor's vault picker, and in the tab strip's vault menu —
+and on the second account after a refresh. Nothing in the vault needs re-encrypting and everybody's key
+still opens it.
 
-**Failure means:** the invited address turning up in a team nobody can see is exactly what revoking pending
-invitations inside the same transaction exists to prevent, and it would happen weeks later on a sign-in
-nobody is watching. Note that taking the freed slug is correct rather than a defect, and is also the reason
-an archived team is only restorable by an operator who checks that first.
+**Failure means:** a name that moved in one place and not another is the shape this rename is most likely to
+fail in, because several screens read it separately from a cached vault row. A vault that stops opening
+after a rename would be far worse, and means that cached row was replaced by the server's answer rather
+than edited — that answer deliberately carries no wrapped key.
 
-### 12.9 Renaming a team, and the slug that does not move
+### 12.9 Somebody who may write to a vault may not rename it
 
-Rename a team and change its description.
+As a plain Member of somebody else's vault, look for RENAME.
 
-**Pass:** the new name is on every screen that names the team, on both accounts after a refresh. The slug is
-unchanged and there is nowhere to change it. Nothing claims to know *when* it was renamed.
+**Pass:** it is not drawn. Adding a host to that vault still works, which is what makes this a boundary
+rather than a broken role.
 
-**Failure means:** a rename that moved the slug could take one an archived team is still holding, and that
-archived team could then never be brought back. An "edited" timestamp anywhere on the screen is invented
-data — `team` has no updated-at column, so there is nothing behind it.
+**Failure means:** a name is what everybody in the vault sees it called, so a member renaming it out from
+under the people who share it is an administrative act reached without the role for it. The server refuses
+it too — this is the interface not offering what the server would turn down.
 
 ---