fix: removing someone who never redeemed their invitation

A member row appears only when a code is consumed, so revoking someone
invited to the wrong group was refused for having no row — and the node's
refusal aborted the browser's removal before its hub half, leaving them a
member everywhere with a live code. Revoking now cancels unredeemed codes
for that group, and a node refusal no longer cancels the hub removal.

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

1 files changed, 8 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index b9fdbdc..555d0f1 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -383,6 +383,14 @@ Four properties, each load-bearing:
    rotation propagates by itself and revocation actually takes effect. (Rotating
    the key after a revocation is still required — the ex-member holds the current
    one, and no protocol can take that back.)
+5. **Revoking somebody cancels the code they have not redeemed yet**, for that
+   group and no other. There is no membership until a code is consumed, so an
+   invitation sent to the wrong person is the whole of their access, and a
+   removal that left it usable would be a removal in name only. It is also the
+   case removal is asked for most: an invitation is undone before it is
+   accepted, not after. Nothing to rotate then — they never held the key, and
+   `member_revoke` says so by returning no reminder rather than by leaving the
+   caller to work it out.
 
 Node authority is established the same way, once per node: `meshbay-node operator
 pair` prints a code, the operator types it into their own browser, and the node