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/design-import-gaps.md

@@ -30,7 +30,8 @@ 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 because a vault arrives without being asked for.
+> design had no slot for — and it is on the phone because a vault arrives without being asked for, and
+> because somebody can be let into one from there.
 > 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