Two failures, one note slot: a share click erases the list error, and the next poll erases the share error #992

Symptom

Sharing → Share with a friend keeps one note for two independent failures (the friend list read, and a Share click), so each one destroys the other. Two directions, both user-visible:

1. A share click wipes the list's error. Rows are stale and the card says the read failed with Try again (note = { tone: 'error', source: 'list' }). Click Share: share() starts with setNote(null) (:3188), so the list error and its Try again are gone before the request even leaves. If the share then fails, the slot holds source: 'share' (:3202) — the card now reads a share error and offers no retry, while the rows are still from the last successful read.
2. The next poll wipes the share's error. A failed read writes source: 'list' (:3170) into the same slot, so within 5 s the share's own message is replaced by the list's, and the user loses what he was just told about his click.

Reviewer named this as non-blocking #2 on #989; this issue is that non-blocking, because the card ends up stating neither failure correctly.

Where (main b3abe396, plugins/social/client.js, ShareWithFriend)

• One slot: :3152 const [note, setNote] = useState(null).
• Write entries: list error :3170; share start clears everything :3188; share ok :3196; share error :3202.
• Read success settles only the list error: :3165 (previous?.source === 'list' ? null : previous).
• Empty sentence gate: :3211 (note?.source !== 'list').
• Try again belongs to the list error: :3228-3231 (note.tone === 'error' && note.source === 'list' at :3229).
• The only reset for both is a remount: :3173-3175.

Expected

Both facts can be on screen at once, and neither can erase the other:

• A failed list read keeps its error and Try again when a Share is clicked, and still has them after that Share fails.
• A share's error survives the next failed poll; only a later share outcome replaces it.
• A successful read settles the list error only; a successful share settles the share outcome only.
• The empty sentence is suppressed by a list error only; Try again still appears only with a list error.

Acceptance

1. Red test first: rows stale + list error (Try again shown) → click Share, make social/share-with-friend fail → after the click the card still shows the list error and Try again, plus the share's error (or, if one message must win, the list error and its button are still present and the share failure is readable elsewhere on the card). Fails at b3abe396 at :3188 and :3202.
2. Red test, the other direction: share error on screen → the 5 s poll's read fails → the share error is still there (the list error may be shown beside it), not replaced.
3. Guards: a successful read clears only the list error (:3165 semantics preserved); a successful share leaves a list error alone; remount (:3173-3175) still clears both.
4. Empty sentence (:3211) still ignores a share error, and Try again (:3229) is still list-only — both must be asserted, not just preserved by accident.
5. plugins/social suite green; changelog.d/ fragment (the owner sees the difference); docs/subsystems/social.md if the wording of the two notes is documented.

Out of scope

• The read epoch/seq from The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984 (:3156-3167) and the 5 s poll (:3178) — unchanged.
• Never mix the share error with the list error: the retry button must belong to the list read #987's provenance rule (list vs share) — this keeps it and adds the second slot.
• Anything outside ShareWithFriend; core/ and patches/ds-bot/ are untouched, so no regeneration.