The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984

Symptom

Revoke someone in Sharing → People with access: the "Share with a friend" card drops to zero rows and reads "No friends left to share with. Invite someone new above, or they already have this Bot." — a claim about every friend, made right after one person was revoked — and the rows come back only on the next poll.

Why the card can go empty (both in plugins/social/client.js)

1. A failed read is rendered as an empty list. load() (:3145-3154) catches any error from social/share-friends and calls setFriends([]) (:3151), which is the same state as "nobody is left". The empty sentence at :3192-3194 then asserts a fact nothing established.
2. A read taken while the revoke was in flight is written back as truth. :3160 polls every 5s and :3149 assigns whatever comes back; social/revoke-grant drops the roster cache (plugins/social/src/social.js:2553 fetchedAt = 0) and starts remoteBots({ fresh: true }) without awaiting it (:2554), so a read can straddle the revoke. Nothing marks which list is trustworthy, so a bad read replaces a good one and the next poll replaces it again.

First step: which mechanism (cheap, decides the scope)

Reproduce once and record whether the fs-status line (:3209) appears in that same instant:

• error line present → mechanism 1, client-only fix.
• no error line, list genuinely [] from a successful social/share-friends → mechanism 2 at the server boundary (social.js:2581-2630), stop and report; that half is a different scope.

Expected

• A read that fails or races the revoke never empties the card: the previous list stays until a read that actually succeeded replaces it.
• "No friends left to share with" only when a read succeeded and returned zero rows.
• A failed read says it failed and leaves a way to retry.

Scope

• plugins/social/client.js, ShareWithFriend only (:3140-3210): separate "never loaded / failed" from "loaded and empty"; only the first successful load may show the empty sentence; do not write back a list from a read that started before the revoke (:2973-2982) finished.
• Keep the 5s poll and the [bot?.id] reset (:3155-3163); no new timer.

Acceptance

1. Red test first: a fake host whose social/share-friends fails once (and, separately, returns [] once) right after a revoke — the card must still show the previous rows plus an error line, and must not print the empty sentence. Red on current main, green after the fix.
2. Second test: a first successful load returning zero rows still prints the empty sentence (that state must stay reachable).
3. A read that resolves after the revoke settled is the only one allowed to replace the list; one that started before it is dropped, not written.
4. No change to the 5s interval, the [bot?.id] reset, or the row keys (friendKey, :3167).
5. plugins/social suite green; changelog.d/ fragment; docs/subsystems/social.md if the user-visible wording changes.

Out of scope

• Row keys and labels: fixed by One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973 (Share with a friend hides a person entirely once one of their Bots has the Bot, and says so inaccurately #981 covers the person-level hiding).
• Grant visibility on the Bot Social side (Sharing the same Bot again after a revoke never reaches the friend: the owner sees the grant, the friend's roster stays empty #970, needs-info).
• "Undo revoke": not asked for, not in this issue.