Merge branch 'main' into claude/host-management-ui-plan-7f20ab

Seven files needed a hand. Most were two branches adding something in the same
place, but three were one branch changing what the other had moved or renamed,
and those are the ones worth reading.

The shell keeps both new fields and both constructor lines: the connection
recorder this branch built and the teams view model main did. Where main put a
teams load inside OnScreenChanged, it now sits beside the logs refresh rather
than inside RaiseSurfaceState — this branch extracted that notification block
and it is called from two properties, so a screen-specific side effect in there
would fire on every terminal switch as well.

Main gave four row types a vault id and a vault name, and this branch had moved
one of them — KnownHostRowViewModel — into its own file when the pinned keys
became a screen. Git resolved that as "deleted here, modified there" and took
the delete, which compiles as long as nobody looks: the moved copy still had
the two-argument constructor and the call site had grown to four. Carried over
by hand, along with the ordering the pins list now does on them.

The status line's quiet rule was the subtle one. Main extracted it into
IsWorthReporting; this branch had changed the same condition to read item
counts rather than raw ones, because every user action queues a log entry a
moment later and this machine reads its own entries back on the next pull. Take
main's structure and the merge builds, passes, and silently restores a bug this
branch existed partly to fix — every save's message overwritten a second after
it appears. The method now reads PulledItems and PushedItems, with the reason
in its remarks.

Two conflicts were prose that had gone stale rather than code. The keychain
screen's comment said team vaults are refused by the server's access service,
which was true when it was written and is not now; main's replacement stands,
in this branch's vocabulary. The design-gaps row for groups was claimed by both
— real host groups here, per-vault headings there — and they are different
things, so both rows stay and the difference is stated: a group is a shelf the
user chose, a vault is who can read the item.

One defect the tests found and the compiler could not. Generating a key opens
the same editor as pasting one, but not through NewKey — so it never set the
target vault main added, and a generated key was filed into whatever vault was
edited last, or none. Both key-generation tests failed on it. Fixed where the
editor opens, with the reason recorded there.

One gap is left deliberately and is written down rather than half-built. Hosts,
keys, credentials and pins are read across every vault this session holds a key
for; groups are read from the active vault alone, so a host a teammate filed
shows under UNGROUPED. Nothing is lost or misfiled — it is what the sidebar
already shows for a group that has been deleted — but closing it needs a vault
id on every group row for rename and delete, and a way to tell two vaults'
identically-named groups apart under a layout with one heading per group. Both
are worth doing and neither is a merge's business. It is in the remarks on
ReloadGroupsAsync and in docs/design-import-gaps.md.

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

README.md

@@ -214,6 +214,42 @@ What is not here: transferring a directory, dragging between the panes, and rout
 bastion — the last needs jump hosts the connection layer has not got. All three are in
 [`docs/design-import-gaps.md`](docs/design-import-gaps.md).
 
+### Working as a team
+
+**TEAMS** in the nav rail creates a team, adds members and shares vaults. One distinction runs through the
+whole screen and is worth having before you use it.
+
+**Adding somebody to a team and giving them a key are two different acts, and only the first is something
+the server can do.** Adding a member changes what the server will *serve* them: the team's vaults appear in
+their list immediately. It cannot make those vaults readable, because a vault key is sealed to each member's
+public key and this server never holds one — so until somebody presses **SHARE KEY** from a machine that has
+the key, their vault sits in the list saying it is waiting for one. That is not a rough edge to be smoothed
+over later; it is what "the operator cannot read the credentials it stores" costs, and the screen says so
+rather than implying the server handed anything out.
+
+Sharing verifies before it wraps. The client reads the server's append-only key log, checks its hash chain
+from the first entry, and refuses unless the key the directory just offered appears in that log unchanged.
+That converts a key substitution by the server from invisible into visible — a substituted key has to be
+published in a log every other client also reads. **It does not prove the key is the right person's.**
+Compare the fingerprint with them over something this server does not carry; that is the only step that
+closes it, and the success message says so every time.
+
+Three limits, stated rather than discovered:
+
+- **Removing a member is not retroactive.** It revokes their grants and flags the team's vaults for rekey,
+  and blocks future reads. Everything they already pulled is on their machine. Rotate the SSH credentials
+  that matter — that is the actual remediation, and it is why there is no button labelled anything stronger.
+- **The rekey is flagged, never performed.** See the milestone note above.
+- **Host key trust stays in your personal vault.** A pin approved for a team's host is recorded and used
+  from your own vault, not the team's, so a teammate cannot pre-approve a fingerprint that your client will
+  then trust silently for a host you defined. The cost is that each member approves a team host's key once
+  on each of their machines. Team vaults' pins are still *listed* on the Vault screen, so you can see what
+  has been trusted.
+
+Items are filed into one vault at a time. When more than one vault is writable, the host and vault editors
+show a picker; it defaults to your personal vault and never moves on its own, because an item put in a team
+vault is visible to everybody in that team and moving it back means deleting and retyping.
+
 ### End-to-end verification
 
 One suite runs against a real server rather than a stub. It needs a Docker daemon and nothing else, so it
@@ -338,7 +374,21 @@ keychain plus a terminal — and the spike that gates all of it.
   directories, an interrupted **upload** starts again rather than resuming (an object cannot be written from
   the middle), and a rename is a copy and a delete rather than one atomic operation. Downloads do resume — a
   ranged GET is part of the protocol, which is the one place a bucket beats SFTP.
-- **M3 — teams**, sharing, ACLs.
+- **M3 — teams**, sharing, ACLs. *Done, except rekey.* Teams with roles, a public-key directory, the
+  append-only key log served for clients to verify against, team-owned vaults, and vault key grants
+  wrapped by a client and stored opaquely by the server. `VaultAccessService` now resolves team
+  membership to permissions, so a viewer may pull and may not push; the desktop client reads and syncs
+  every vault it holds a key for, and a real TEAMS screen replaces the placeholder. See
+  [Working as a team](#working-as-a-team) for the one distinction the whole design rests on, and the limits worth
+  knowing before you rely on it; the reasoning is in
+  [ADR 0009](docs/adr/0009-team-access-model.md).
+
+  **What is deliberately not here: the rekey itself.** Removing a member revokes their grants and flags
+  every team vault `RekeyRequired`, and nothing acts on that flag. A rekey re-wraps every item's data key
+  under a fresh vault key and can only be performed by a client that holds the current one; that is M5's
+  key rotation. Until it lands the flag is what the interface reads to say a rotation is owed, which is
+  more honest than a button that only appears to do it. Ownership transfer is absent for the same kind of
+  reason — the owner cannot be removed or demoted, because nothing can appoint a replacement.
 - **M4 — hardening and ops**, packaging, self-hosting guide.
 - **M5 — multi-provider OIDC**, key rotation, per-item content keys.