Let a vault be shared from the phone, not only read there

This screen's own comment argued ADD out: an address typed into a box, a
directory lookup, a role picker and a paragraph saying what adding somebody did
not do, for an act a colleague at a desktop is already performing.

That was a cost argument and it was wrong about who is holding what. The person
who needs to let somebody into a vault is often the one away from their desk, and
answering them with "go and find a desktop" is the thing this head exists to stop
doing. Making a vault was already here on exactly that reasoning.

Nothing shared changed — AddMemberCommand, the role and the chips are the same
members the desktop binds — so what this is, is markup and the argument it
reverses. Four rows under the members list: the box, three role chips rather than
a picker because the answer is one of three short words, ADD, and the paragraph.
Gated on being able to administer the vault, so a plain member sees nothing
rather than a button whose only outcome is a 403.

The paragraph is not the optional part. Adding somebody changes what the server
will serve and nothing else; the key is still wrapped by a machine that holds one
— which on an unlocked phone is this one, in the same press. A screen that
offered the first and stayed quiet about the second would imply the server can
hand out access, which is the single claim this product is built to refuse.

What the phone still does not draw is anything that takes access away. REMOVE and
WITHDRAW KEY act on the first press, and an irreversible revocation under a thumb
with its explanation in a tooltip no touch screen can show is the wrong trade —
which is the line this file already drew and this does not move.

Check 12.4 walks it, including the locked-keychain case: the membership is made
and the line says the key could not be wrapped, which is a state somebody can act
on rather than silence.

src/DodoSSH.Client.Android/Views/VaultsScreen.axaml

@@ -2,6 +2,7 @@
              xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
              xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
              xmlns:views="using:DodoSSH.Client.Android.Views"
+             xmlns:contracts="using:DodoSSH.Contracts"
              x:Class="DodoSSH.Client.Android.Views.VaultsScreen"
              x:DataType="vm:VaultsViewModel"
              Background="{StaticResource Canvas}">
@@ -45,11 +46,22 @@
     plainer reason: it decides who controls the vault, which is not a thing to do while walking. Nor is
     renaming, which is a keyboard on a screen that is otherwise all reading.
 
-    **ADD is not drawn either**, and it is the operation this screen least needs. It is an address typed
-    into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding somebody
-    did *not* do — five controls for the one act on this screen that a colleague at a desktop is already
-    doing. Making a vault is here, because it is one field and because it is what a person carrying a
-    phone can usefully start.
+    ◆ **ADD is drawn, where it was not.** The argument against it was that it is an address typed into a
+    box, a directory lookup, a role picker and a paragraph saying what adding somebody did *not* do — five
+    controls for an act a colleague at a desktop is already performing. That was a cost argument and it was
+    wrong about who is holding what: the person who needs to let a colleague into a vault is often the one
+    away from their desk, and telling them to go and find one is the same answer this head exists to stop
+    giving. Making a vault was already here on exactly that reasoning.
+
+    What it costs is four rows under the members list rather than five controls, because three of them are
+    the role and are chips rather than a picker — the same chips the host editor wears for tags, so the
+    choice is visible without being opened. It is gated on being able to administer the vault, so on a
+    membership where the answer would be a refusal there is nothing to press.
+
+    **The paragraph comes with it and is not the optional part.** Adding somebody is a change to what the
+    server will serve and nothing else; the key still has to be wrapped from a machine that holds it, which
+    on this head is the bar below. A screen that offered the first and stayed quiet about the second would
+    be implying the server can hand out access, which is the one claim this product is built to refuse.
 
     **The key-holder list is not drawn.** It is a third list, and what the phone can answer about a vault
     is the more useful half of the same question and is on the vault's own row: whether *this* machine can
@@ -243,6 +255,64 @@
             <TextBlock Classes="body" Margin="18,10,18,0"
                        Text="Being in a vault is what lets the server hand somebody its rows. It is not what lets them read one: a vault key can only be wrapped by a machine that already holds it, which is what sharing below does." />
 
+            <!-- ============ ◆ adding somebody ============ -->
+            <!--
+              In the scrolling column rather than in the bar at the foot, and that is deliberate. The bar is
+              raised by choosing a *member* and is about that member; this is about the vault and is
+              available with nobody chosen at all, so putting it there would mean selecting somebody in
+              order to add somebody else.
+
+              Only for an admin or the owner. The server refuses anybody else and says so, but a box and a
+              button that exist to produce that refusal are worse than an absence — see
+              VaultsViewModel.CanAdministerSelected, which is the same gate the desktop uses.
+
+              The role is three chips rather than a ComboBox, matching the tag chips in the host editor: the
+              answer is one of three short words, and a picker would hide two of them behind a tap. Member
+              is the default because it is what adding a colleague almost always means; viewer would be
+              safer and would be the wrong default, since an interface whose default is wrong teaches people
+              to change it without reading it.
+            -->
+            <StackPanel IsVisible="{Binding CanAdministerSelected}" Spacing="8" Margin="18,18,18,0">
+
+              <TextBlock Classes="section" Text="ADD SOMEBODY" />
+
+              <TextBox Classes="field" Text="{Binding NewMemberEmail}"
+                       PlaceholderText="colleague@example.com" />
+
+              <TextBlock Classes="label" Text="THEY ARRIVE AS" Margin="0,2,0,0" />
+
+              <StackPanel Orientation="Horizontal" Spacing="6">
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsViewer}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Viewer}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="VIEWER" />
+                </Button>
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsMember}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Member}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="MEMBER" />
+                </Button>
+                <Button Classes="chiptoggle" Classes.worn="{Binding AddsAsAdmin}"
+                        Command="{Binding ChooseNewMemberRoleCommand}"
+                        CommandParameter="{x:Static contracts:TeamMemberRole.Admin}">
+                  <TextBlock Classes="mono" FontSize="11.5" Text="ADMIN" />
+                </Button>
+              </StackPanel>
+
+              <Button Classes="primary" Height="44" Content="ADD"
+                      Command="{Binding AddMemberCommand}" IsEnabled="{Binding !IsBusy}" />
+
+              <!--
+                The half of the act the server cannot perform, said before it happens rather than discovered
+                afterwards. Adding somebody from this phone wraps every vault key this phone can open to
+                them as part of the same command — so on an unlocked handset it is one press, and on a
+                locked one it is a membership and an owed key, which the status line then says.
+              -->
+              <TextBlock Classes="body"
+                         Text="Adding somebody lets the server serve them this vault. It does not let them read it: a vault key is wrapped by a machine that already holds one, so this phone does that too if it can open the vault. An account that has never signed in to this server cannot be added — ask them to sign in once first." />
+
+            </StackPanel>
+
           </StackPanel>
 
         </StackPanel>