Share with a friend hides a person entirely once one of their Bots has the Bot, and says so inaccurately #981

Follow-up to #973, non-blocking there (Reviewer's note at 6384838825): the share panel still decides "does this friend already have this Bot?" per person, not per Bot, so a friend's second Bot disappears from the list and the panel then tells a small lie about it.

Today

• plugins/social/src/social.js:2586-2597 — shareFriendsForBot() lists this Bot's live grants and collects grantedHomes from grantPersonView(grant)'s home, i.e. one home key per person, no Bot id.
• :2601 — if (… || grantedHomes.has(homeKey)) continue: once any of that friend's Bots has the grant, every Bot of theirs is skipped.
• :2603-2612 — so the row that would let you share with their second Bot is never built. #973 fixed the label and the per-Bot rows for friends who have no grant; it deliberately left this filter alone.
• plugins/social/client.js:3187 — with the list empty the panel says "…or they already have this Bot", which is false for the friend's other Bot.

Reviewer's read on the repair: grantPersonView(grant).member already distinguishes the granted Bot, so the fix needs no new server field and no waiting on list_bot_grants.

Expected

• A friend with two Bots, one already granted: the ungranted Bot still appears, one row naming it (Writer (Bob)), and clicking it grants that Bot.
• A friend whose every Bot already has it: no row for them, and the "they already have this Bot" sentence is then true.
• No home-level collapse: two rows from one home stay two rows (#973 keyed them per Bot), and the busy/Sharing… state stays per row.

Acceptance

1. Fixture: friend Bob with Bots A and B, A already granted → the list has one row, for B, naming B. Today it has zero rows.
2. Friend with both granted → zero rows, and the empty sentence is accurate.
3. Friend with neither granted → two rows (unchanged from One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973).
4. The grant the click sends names B's peerBotId — asserted on the fake server's recorded grant_bot_to_friend arguments, not on the row's shape.
5. No change to the "no friends left" sentence in the case where it is accurate; if the sentence needs a second variant (“every Bot of theirs already has it”), one sentence, not a list.

Where

plugins/social/src/social.js:2586-2612 (grantedHomes keyed by grantPersonView(grant).member instead of the home); plugins/social/test/social.test.js next to the #973 cases; docs/subsystems/social.md only if the sentence changes.

Red proof

On 90ff273d, a fixture with one granted Bot of a two-Bot friend builds no row for that friend — red — while the same fixture with the grant removed builds two. Restoring the home-keyed filter must reproduce exactly the first red.

Notes

• Not part of One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973: that PR's acceptance is about naming the receiving Bot; this is which Bots are offered at all.
• The same grantedHomes set is used for nothing else, so the change stays inside this function.

Written-by: Triage