fix(client): link a device from the application; approve one match only

"Get a linking code" called the connection the page had just closed on the
node's unknown_device refusal, so it never filed anything. It now retries
with the request filed on that connection, before the proof (MNP 6.3), and
the page tries the group again after each refusal until a linked device
approves the code. Offered only in the desktop application: a browser's
minted identity is gone by its next connection.

Approving refuses a code that matches more than one pending request:
filing needs only the account's token, so somebody holding the passphrase
who saw a code could file their own keys under it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2 files changed, 12 insertions, 1 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 6dd1b2e..49baa6a 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -283,7 +283,11 @@ new_pk_x25519)`. The approving device asks the node for this account's pending
 requests **with their stored hashes** and recomputes the hash for each until one
 matches. **An approval answers a pending request**: it names the request's hash,
 and the node admits the keys only if that request was filed by those same keys. A
-countersignature alone — however it was obtained — admits nothing. Retiring a
+countersignature alone — however it was obtained — admits nothing. **A code that
+matches more than one pending request approves none**: filing needs only the
+account's token, so somebody holding the passphrase who saw the code could file
+their own keys under it, and the first match would then be whoever filed first.
+The new device shows a new code instead. Retiring a
 device is signed under a prefix of its own, never the admission transcript: a
 signature given to retire a key would otherwise admit it.
 
diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md
index 8372ee7..b1f7644 100644
--- a/docs/MESHBAY_NODE_PROTOCOL.md
+++ b/docs/MESHBAY_NODE_PROTOCOL.md
@@ -994,6 +994,7 @@ answered with the group key, like any pinned device's.
       |                        |     A recomputes sha256(code||keys)
       |                        |     for each candidate and keeps the match.
       |                        |     No match -> refuse before signing.
+      |                        |     More than one -> refuse: approve none.
       |                        |                              |
       |                        |<--- device_add --------------|
       |                        |     {pk_ed25519, pk_x25519,  |
@@ -1006,6 +1007,12 @@ answered with the group key, like any pinned device's.
       |                        |     {pk_ed25519}             |
 ```
 
+A request is filed with the account's token alone, before any proof (§7). So
+anyone holding the passphrase who has seen a code on D's screen can file a second
+request with that code and keys of their own, and both hashes verify. That is why
+A approves only a code that matches **exactly one** pending request; D then shows
+a new code.
+
 ### 9.2 Transcripts
 
 ```