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.

src/DodoSSH.Contracts/ProblemCodes.cs

@@ -135,30 +135,24 @@ public static class ProblemCodes
     /// <remarks>
     /// <para>
     /// Its own code rather than folded into <see cref="InvalidTeam"/> because it is the one add failure
-    /// with a remedy the client can take unprompted: there is nobody to add, so invite the address
-    /// instead. A client that could not tell this apart from a rejected role would have to either
-    /// invite on every failure or never.
+    /// that is not about the request: the request was fine and named somebody who is not here. A client
+    /// that could not tell this apart from a rejected role would have to say "check what you typed"
+    /// about an address that was typed correctly.
     /// </para>
     /// <para>
-    /// It answers whether an address has an account here, which <c>CreateTeamInvitationRequest</c>
-    /// deliberately does not. The exposure is bounded by the same authorization the add already needs —
-    /// only an admin or owner of the team reaches it — and it is what the caller learns anyway the
-    /// moment the account appears in the member list.
+    /// <b>Nothing follows it.</b> This used to be the signal to invite the address instead; there are
+    /// no invitations, and a membership is only ever granted to an account somebody named, so the whole
+    /// of what a client can do with this is say that the person has to sign in here once. See
+    /// <see cref="AddTeamMemberRequest"/>.
+    /// </para>
+    /// <para>
+    /// It answers whether an address has an account here, which is a real disclosure and a bounded one:
+    /// only an admin or owner of the team the add names reaches it — the endpoint checks that first —
+    /// and it is the same fact the member list would show them a moment later.
     /// </para>
     /// </remarks>
     public const string NoSuchAccount = "no-such-account";
 
-    /// <summary>
-    /// An invitation was rejected: a malformed address, an unknown or ownership role, an expiry the
-    /// server will not issue, or an address that already has an account here.
-    /// </summary>
-    /// <remarks>
-    /// Separate from <see cref="InvalidTeam"/> because the most common cause has its own remedy that a
-    /// client can act on — an address that already has an account should be added through the
-    /// directory instead, which is the path that shows the caller the key they are about to trust.
-    /// </remarks>
-    public const string InvalidTeamInvitation = "invalid-team-invitation";
-
     /// <summary>
     /// A vault key grant was rejected: a fingerprint or wrap of the wrong size, a generation that is
     /// not the vault's current one, or a recipient who cannot reach the vault in the first place.