Let a team be joined only by somebody who is already here

An invitation decided access from an assertion about an address. Everything else
in this model decides it from something a person did — an admin naming an
account, a key holder wrapping a vault key to a key they verified — and this was
the one place a token's email claim was the thing that let somebody in.

It was guarded as tightly as that can be guarded: the claim was refused outright
on an unverified or absent `email_verified`, with no setting to relax it. But the
guard and the risk were the same shape. The whole defence was one boolean sent by
a system the deployment does not control.

So `POST /teams/{id}/members` is the only way in, and an address with no account
is refused with `no-such-account` — which is now the end of the road rather than
the signal to invite. Both clients say the remedy: that person signs in here
once, which is what creates the account, and then they can be added. The desktop
leaves the address in the box, because a message telling you to come back later
is one you act on later.

Gone with it: the `team_invitation` table, the claim hook in the sign-in path,
and `Oidc:EmailVerifiedClaim`, which that hook was the only reader of. Nothing in
the server now reads the email claim to decide anything.

Pending invitations are dropped rather than converted. Converting one would mean
creating a membership because an address matched, which is the property being
removed — and an invitation to an address that did have an account here had
already been claimed by the hourly sweep, so what is left is offers to people who
never arrived.

Two tests carry the property rather than the feature: the endpoint inventory
asserts the three routes are absent, and the API suite adds an address that has
no account, watches the refusal, then signs that address in and checks it joined
nothing. Without the second half, a server that merely renamed the deferred path
would pass.

docs/design-import-gaps.md

@@ -30,11 +30,11 @@ the chrome, hosts and terminals, file transfer, the vault, teams, and preference
 > SFTP and S3 are one screen over one `TransfersViewModel`, differing only in which picker they offer.
 >
 > **A sixth is behind MORE that v2 never drew: VAULTS.** It is the reverse case — a shipped screen the
-> design had no slot for — and it is on the phone for a reason the design could not have anticipated,
-> because invitations did not exist when it was drawn. An invitation is claimed by *signing in*, and the
-> person being invited is at least as likely to be holding a phone as sitting at a desktop; a vault the
-> server has just put somebody in, visible only on a head they may not have installed, is a membership
-> they cannot see. It runs over the same view model the desktop screen drives, like the other four.
+> design had no slot for — and it is on the phone because a vault arrives without being asked for.
+> Somebody wraps its key to you from their machine, and the person it arrives for is at least as likely to
+> be holding a phone as sitting at a desktop; a vault the server has just put somebody in, visible only on
+> a head they may not have installed, is a membership they cannot see. It runs over the same view model
+> the desktop screen drives, like the other four.
 >
 > | v2 element | What ships instead |
 > | --- | --- |
@@ -195,12 +195,13 @@ unused tables bought. See [Vaults](#vaults). What has *not* changed is the split
 decides what it will serve, and only a client can decide who can read it — so "shared with" is two facts on
 this screen, not one.
 
-One table did have to be added, and what it shows is the limit of that reservation. An invitation names an
+One table was added and then dropped again, and the round trip is worth a line. An invitation named an
 **address**, and `team_membership.user_id` is not nullable and carries a foreign key, so somebody who has
-never signed in has nothing for that row to point at — which is why `MembershipStatus.Invited` has been
-reserved since the first migration and is still never written. `team_invitation` is its own table for that
-one reason. The schema was right about the shape of a team and had said nothing about the shape of joining
-one.
+never signed in had nothing for that row to point at — which is why `MembershipStatus.Invited` has been
+reserved since the first migration and has never once been written. `team_invitation` existed for that one
+reason and is gone: membership is granted only to an account that exists, so there is no longer a shape the
+reservation fails to cover. The status stays reserved, because the column holds it in nobody's database and
+a client must not fail on a value a later server might send. See [ADR 0009](adr/0009-team-access-model.md).
 
 **The client has no preferences store.** It writes exactly two files — `cache.db` and `device.key` — and the
 cache has six tables, none of them settings. Nothing on the design's TERMINAL preferences panel can be
@@ -394,9 +395,8 @@ drew around them.
 ## Vaults
 
 **Built in M3, and reshaped since.** The screen ships: a vault list, a members table with a real
-last-active column, the invitations standing against addresses that have no account here yet, who holds a
-key, and the two buttons the whole design was really about — add somebody, and share a vault key. A vault
-can also be renamed and handed to another member.
+last-active column, who holds a key, and the two buttons the whole design was really about — add somebody,
+and share a vault key. A vault can also be renamed and handed to another member.
 
 **It lists vaults where it used to list teams, and that is the reshaping.** A team is still what the server
 authorises against; what went is the requirement that anybody make one. Naming a vault makes the membership
@@ -416,15 +416,19 @@ place that changed, exactly as its remark predicted, and no migration was needed
 What the row did not anticipate is that the interesting half is not the endpoints at all. It is that
 **membership and readability are different things**, and the screen is arranged around saying so.
 
-**There are two ways into a team and they are not interchangeable.** Adding a member takes a *user id* the
-caller has already got from the directory, so that account must have signed in here at least once — and the
+**There is one way into a team, and that is the decision.** Adding a member takes a *user id* the caller
+has already got from the directory, so that account must have signed in here at least once — and the
 ordering is deliberate rather than incidental, because whoever adds a member is usually about to wrap a
-vault key to the public key that lookup returned. Inviting takes an *address*, grants nothing readable, and
-cannot be a step towards sharing: there is no account, so there is no key to wrap to. Inviting an address
-that already belongs to a member of this team is refused and says so — that is a fact about a team the
-caller can already see. Inviting one that merely has an account somewhere on this deployment is **not**
-refused, because answering that would turn the endpoint into an oracle for which addresses have accounts,
-answerable by anybody willing to create a team first. It simply gets claimed sooner.
+vault key to the public key that lookup returned. An *address* is accepted too, and has to be: the
+directory lists only accounts that have published a key, so everybody between a first sign-in and their
+enrollment is invisible there and would otherwise be unaddable. What is refused is an address with no
+account at all, under `no-such-account`, and that refusal is the end of the road — the remedy is that
+person signing in once.
+
+There was a second way in, and there is not any more. An invitation took an address, waited, and became a
+membership the next time somebody signed in asserting it. It is gone because it was the one place in this
+product where access followed from an identity provider's claim about an address rather than from somebody
+naming an account. See [ADR 0009](adr/0009-team-access-model.md).
 
 | Design element | Layer | What ships |
 | --- | --- | --- |
@@ -436,17 +440,16 @@ answerable by anybody willing to create a team first. It simply gets claimed soo
 | Adding a member shares the team's vaults | client | Adding somebody wraps every team vault the adding machine can open to them, as part of the add rather than as a button to remember. Membership and a key are still two acts on two machines; the client just performs both. A vault this machine holds no key to is skipped and named. |
 | Removing a member rotates the vaults | server + client | `POST /api/v1/vaults/{id}/rekey` advances the generation and records the caller's new grant in one transaction — the server contributes the moment and no cryptography. The client then wraps the new key to the members who remain. Grants for earlier generations are kept, or the vault's stored items would become unreadable to everybody. See [ADR 0010](adr/0010-vault-key-rotation.md). |
 | Re-sealing a rotated vault's stored items | client | `VaultResealer`, the last step of a rotation: every item is opened and the same plaintext sealed again under the new key, in batches, against the version the server holds. The plaintext is never decoded, so an item written by a newer client crosses a rotation untouched. Resumable, because a vault at mixed generations is readable — a pass that stops half way leaves a working vault and is re-run. A change queued before the rotation is re-sealed by the push path instead, so nothing reaches the server under a superseded key at all. |
-| Pending invites, and withdrawing one | server | A `team_invitation` row per (team, address), listed beside the members it is about and withdrawable until it is taken up. It becomes a membership when an account with that address signs in — **and only if the access token asserts `email_verified`**, because membership is authorisation and an invitation anybody could take by naming somebody else's address is a way in. Fourteen days, because an address that is reassigned would otherwise carry a standing offer to whoever holds the job next. |
 | Ownership transfer | server | `POST /api/v1/teams/{id}/owner`, owner only. One transaction: the named member becomes owner and the outgoing owner becomes an admin. Not two role changes — ownership is sole, so promoting first leaves the team owned twice and demoting first leaves it owned by nobody. The outgoing owner is demoted rather than removed, because removing them would revoke their vault key grants and rotate every team vault, which is a far larger act than the one being asked for. |
 | `LAST ACTIVE` | server | Real, and coarse on purpose. `UserAccount.LastSeenAtUtc` is now refreshed on ordinary authenticated requests, at most once per account per hour: writing it per request would put an UPDATE on the hot path of every authenticated call and start losing races on `user_account`'s own concurrency token. So the column answers "this week or not", which is the granularity the question is actually asked at, and is shown coarsely rather than to the minute. |
-| Renaming and archiving a team | server | `PUT` and `DELETE /api/v1/teams/{id}`. The slug is deliberately not renameable: it is unique only among *live* teams, so a rename could take a slug an archived team still holds and strand it. Archiving soft-deletes the team, every membership and every pending invitation in one transaction — and is refused outright while the team owns any vault. |
+| Renaming and archiving a team | server | `PUT` and `DELETE /api/v1/teams/{id}`. The slug is deliberately not renameable: it is unique only among *live* teams, so a rename could take a slug an archived team still holds and strand it. Archiving soft-deletes the team and every membership in one transaction — and is refused outright while the team owns any vault. |
 
 | Design element | Layer | What it would take | What ships instead |
 | --- | --- | --- | --- |
 | `CONNECT-ONLY` role | — | Nothing that would be true. Connect is a user-interface hint, not a boundary: SSH terminates on the client, so a session needs the credential's plaintext on that machine. See ADR 0001. | Four roles, all of which are enforceable. `Connect` rides along with `Read` and is documented as a hint. |
 | `2FA ENFORCED` and the per-member 2FA column | server | No two-factor concept exists anywhere — the only hit in the whole worktree is an aside in `docs/crypto.md`. | Omitted. The member columns carry what *is* known and matters: whether they have published a key a vault can be wrapped to, and when they were last here. |
 | Avatars | server | No picture is stored anywhere. | Omitted; the row shows a name and an address. |
-| The invitation mail, and **resend** | server | An outbound mail path: an SMTP configuration, a template, a bounce story and a deliverability problem, none of which this server has. | **Nothing is sent, and the interface says so.** An invitation is a standing instruction rather than a message — the next account to sign in with that address joins the team — so there is no token, no link, and nothing to resend. Telling somebody to sign in is done over a channel this server does not carry. A link nobody can deliver would be worse than no link. |
+| Pending invites, the invitation mail, and **resend** | server | An outbound mail path this server has not got, and — the larger cost — a rule that turns an identity provider's claim about an address into team membership. | **Nothing pending exists, and the screen says why.** Only an account that already exists can be added; an address with no account is refused, naming the address and saying the person has to sign in here once. There was a `team_invitation` table doing the deferred version of this and it has been dropped. See [ADR 0009](adr/0009-team-access-model.md). |
 | Archiving a team that owns vaults | — | Nothing that would be safe. A team vault resolves through membership, so archiving would take those vaults away from everybody holding a key, silently, including the caller — and nothing in this product deletes a vault, so there is no sequence of calls that turns the refusal into a success. | Refused, with `team-not-empty` and a count of the vaults in the way. A stated limit rather than a coming feature, for the reason the SFTP layer refuses a recursive delete: a refusal is visible and a quiet removal is not. |
 | `SSO · OIDC · okta.dodotech.dev` | server | Per-team SSO. Authentication is one global JWT scheme bound to one authority. | Omitted. |