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.

docs/manual-checks.md

@@ -1427,6 +1427,29 @@ instead — distinct from the "no account here" refusal in 12.1, because the two
 **Failure means:** the two refusals reading alike leaves somebody checking what they typed when the answer
 is that the person is already in.
 
+### 12.4 Somebody can be added from the phone, and the key goes with them · **needs a device and two accounts**
+
+On the phone: Settings → Vaults, choose a shared vault this account administers.
+
+**Pass:** under the members list there is an ADD SOMEBODY box, three role chips with MEMBER lit, an ADD
+button, and a paragraph saying that adding lets the server serve them and does not let them read anything.
+On a vault this account only belongs to, none of that is drawn at all — not greyed, absent.
+
+Type a colleague's address and press ADD, with the phone unlocked.
+
+**Pass:** they appear in the members list, and the status line says both halves — that they were added, and
+what happened to the key. On an unlocked phone that holds the vault key it says it shared it; the colleague
+syncs and the vault opens.
+
+Now lock the phone's keychain and add somebody else.
+
+**Pass:** it refuses to pretend. The membership is made and the line says the key could not be wrapped
+because this keychain is locked — which is a state somebody can act on, unlike silence.
+
+**Failure means:** a screen that adds somebody and says nothing about the key is implying the server can
+hand out access, which is the one claim this product exists to refuse. ADD drawn for a plain member is a
+button whose only outcome is a 403 from the server.
+
 ### 12.5 LAST ACTIVE is a real time, and a coarse one · **needs a couple of hours**
 
 Use one account and leave the other idle for two or three hours, then read the members table.