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.Client.App/Views/VaultsScreen.axaml

@@ -12,7 +12,7 @@
     The left column used to list teams; a team owned vaults, and sharing meant creating a team, then a
     vault in it, then wrapping a key. Two of those three steps were about a concept nobody came here for.
     So the rows are vaults now: naming one makes the membership list that carries it, and everything on
-    the right — members, invitations, key holders — is that vault's. The server still authorises against
+    the right — members, key holders — is that vault's. The server still authorises against
     a team, because that is what VaultAccessService resolves; what went is the requirement that a person
     know it exists. The one case where it is still visible is a membership list carrying several vaults,
     which this screen cannot make and will not hide: see SharedMembershipWarning.
@@ -25,11 +25,12 @@
     than a checkbox on the member row.
 
     What the design asked for and is still not here: two-factor state (no such concept exists anywhere in
-    this product) and avatars (no picture is stored anywhere). Nothing is sent for an invitation — there
-    is no outbound mail path and no token, so an invitation is a standing instruction that the next
-    account signing in with that address joins, and there is consequently nothing to resend. Last-active
-    is recorded at most once per account per hour, so it is drawn coarsely. Nor is there a way to delete a
-    vault: the server has no such call, and the screen says so rather than offering a button that refuses.
+    this product) and avatars (no picture is stored anywhere). There is no INVITED list either, and that
+    one is a decision rather than a gap — an address is not a way into a vault, so only an account that
+    already exists can be added and there is nothing pending to draw. See the ADD box below, which says
+    what to do about somebody who has not signed in here yet. Last-active is recorded at most once per
+    account per hour, so it is drawn coarsely. Nor is there a way to delete a vault: the server has no
+    such call, and the screen says so rather than offering a button that refuses.
   -->
 
   <Grid ColumnDefinitions="268,*">
@@ -261,11 +262,11 @@
             </StackPanel>
 
             <Grid ColumnDefinitions="*,Auto,Auto" IsVisible="{Binding CanAdministerSelected}">
-              <TextBox Grid.Column="0" PlaceholderText="colleague@example.com" Text="{Binding InviteEmail}"
-                       Margin="0,0,6,0" />
+              <TextBox Grid.Column="0" PlaceholderText="colleague@example.com"
+                       Text="{Binding NewMemberEmail}" Margin="0,0,6,0" />
               <Button Grid.Column="1" Classes="accent" Content="ADD"
                       Command="{Binding AddMemberCommand}" IsEnabled="{Binding !IsBusy}"
-                      ToolTip.Tip="Adds the account with this address, or invites the address if there is no account here yet. Nothing is sent either way — tell them yourself." />
+                      ToolTip.Tip="Adds the account that signs in with this address. An address with no account here is refused and says so — ask them to sign in to this server once, which is what creates the account, and then add them." />
               <Button Grid.Column="2" Classes="danger" Content="REMOVE" Margin="6,0,0,0"
                       Command="{Binding RemoveMemberCommand}" IsEnabled="{Binding !IsBusy}"
                       ToolTip.Tip="Removes the selected member and withdraws every key they hold to this vault. It blocks future reads only — anything already on their machine stays there, so rotate the credentials that matter." />
@@ -291,40 +292,6 @@
                        Text="Adding somebody lets the server serve them this vault. It does not let them read it: a vault key can only be wrapped by a machine that already holds it, which is what SHARE KEY below does." />
           </StackPanel>
 
-          <!--
-            Invitations, drawn only when there are any. An empty INVITED heading on every vault would be
-            a permanent reminder of a feature most people never use.
-          -->
-          <StackPanel Spacing="8" IsVisible="{Binding HasInvitations}">
-            <Border Height="1" Background="{StaticResource BorderSubtle}" />
-
-            <TextBlock Classes="label" Text="INVITED" />
-
-            <ListBox ItemsSource="{Binding Invitations}" SelectedItem="{Binding SelectedInvitation}"
-                     Background="Transparent" BorderThickness="0" MaxHeight="160">
-              <ListBox.ItemTemplate>
-                <DataTemplate x:DataType="vm:VaultInvitationRowViewModel">
-                  <Grid ColumnDefinitions="*,Auto" Margin="0,3">
-                    <StackPanel Grid.Column="0" Spacing="2">
-                      <TextBlock Text="{Binding Email}" FontSize="13" FontWeight="Medium"
-                                 Foreground="{StaticResource Text}" TextTrimming="CharacterEllipsis" />
-                      <TextBlock Classes="hint" FontSize="11" Text="{Binding State}"
-                                 TextWrapping="Wrap" />
-                    </StackPanel>
-                    <TextBlock Grid.Column="1" Classes="mono" Text="{Binding Role}" FontSize="10"
-                               Foreground="{StaticResource TextFaint}" VerticalAlignment="Center"
-                               Margin="10,0,0,0" />
-                  </Grid>
-                </DataTemplate>
-              </ListBox.ItemTemplate>
-            </ListBox>
-
-            <Button Classes="danger" Content="WITHDRAW INVITATION" HorizontalAlignment="Left"
-                    Command="{Binding RevokeInvitationCommand}" IsEnabled="{Binding !IsBusy}"
-                    IsVisible="{Binding CanAdministerSelected}"
-                    ToolTip.Tip="Signing in with that address will no longer put them in this vault. An invitation already taken up is a membership — remove the member instead." />
-          </StackPanel>
-
           <Border Height="1" Background="{StaticResource BorderSubtle}" />
 
           <!-- Who holds the key -->