fix(hub): a redeemed invitation link leaves the owner's list

The list under "Invite by link" answered every ticket the group had ever
minted, so a link that somebody had already used sat there saying "used by
<name>" for the thirty days of KEEP_REDEEMED — beside the member row it had
just produced, and above the links that still wait for somebody, which are
the only ones there is anything to do about. The node's own `member list`
had never shown them: it selects `used_at IS NULL`.

The listing now selects `redeemed_by IS NULL`, and drops the `redeemed`
status and the `redeemed_by` field with it. The row itself still lives for
KEEP_REDEEMED, which is what lets a reload or a second tab of the invitation
page be answered rather than refused; its comment says that now instead of
naming a list it is no longer in.

The SPA filters too, because the desktop client's copy of this interface can
be newer than the hub it is signed into.

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

2 files changed, 10 insertions, 3 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 673ad05..325a3c5 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1811,7 +1811,12 @@ account, and an unknown, used, expired or cancelled ticket, or a group no longer
 active, is one uniform refusal. Creating a link says nothing about whether the
 address has an account (**M1**). At most twenty outstanding per group, as on the
 node; a lifetime clamped to thirty days; a node token may create one for its own
-operator's group (the CLI) and may not ask for mail. What the binding holds
+operator's group (the CLI) and may not ask for mail. **The list answered to the
+owner holds the links nobody has used yet**, which are the ones there is still
+something to do about: a redeemed one has become the member row it produced, and
+showing both says the same thing twice. The row itself outlives the list by
+thirty days, so the account that used a link is answered on a reload or in a
+second tab rather than refused. What the binding holds
 against, per the convention: **third parties** — a messaging service that
 previews the link, a forwarded mail — and not this hub, which verifies the
 addresses it compares and could already be anybody.
diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index d3676cf..0589929 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -579,8 +579,10 @@ their e-mail address and **Create link**. Send them the
 link, or leave **Send the invitation by e-mail** ticked and the hub mails it.
 They register with that address and land in the group without typing a code.
 The link works once and only for an account with that address, so a copy that
-travels further — a forwarded mail, a chat — lets nobody else in. Pending links
-are listed under the box, and **Cancel** takes one back. A hub mails at most ten
+travels further — a forwarded mail, a chat — lets nobody else in. Links nobody
+has used yet are listed under the box, and **Cancel** takes one back; once
+somebody joins through a link it leaves that list, and they are in the member
+list above it. A hub mails at most ten
 links a day for one account (an administrator can change that).
 
 The Members tab offers **Send the invitation by e-mail**, ticked by default: the