Nothing pins the held-reply seam: a terminal failure must arrive as retry:false in the channel view #986

What is missing

A held reply's Retry is decided by one rule (canRetry, core/src/shared/held-retry.js), and the two ends of that path are each pinned — but nothing pins the middle, where the host's hold record becomes the Bot view the client draws from. A retry: false that never arrived would still draw a button, and every test we have would stay green.

The path, at main 99cbb1a1:

1. core/src/host/hooks.js:515 — rt.heldRepliesOf = (botId) => [...autoSentOf(botId), ...heldOf(botId)]; heldOf is where noRetry: true / retry: false / a terminal stored error become retry: false.
2. core/src/host/channel.js:133 reads that list and :143 puts it on the Bot view: ...(held.length ? { heldReplies: held } : {}). This is the seam — the view is passed on unchanged, or not at all.
3. core/src/client/text.js:269 heldReplyOf(bot, sessionId, turn) reads bot.heldReplies; core/src/client/cells.js:158 uses it; core/src/client/held-reply.js:57 draws Retry only when canRetry(held); the session dock card is core/src/client/flybot-slots.js:303-304.

Why the gap is real

• core/test/host-approval-status.test.js asserts view.bots[].heldReplies statuses through the host, but never a terminal failure, so it does not pin retry: false surviving step 2.
• core/test/held-reply.test.js builds the roster by hand (chief(heldReplies) → { heldReplies }), so it starts at step 3 and pins only what the renderer does with a flag someone already put there.
• Consequence: delete the spread at channel.js:143 (or stop mapping retry in heldOf), and no test turns red — while a terminal failure draws a Retry that cannot work (A failed card that can never succeed still offers Retry: two core cards never read the flag, and #961 fixed only the social dock #968's whole point). Reviewer2 flagged this on Read a gone friend's Bot as one sentence and drop the useless Retry #961 and Reviewer on #968: one predicate decides whether a failed card can retry #975; neither was in scope there.

Expected

One end-to-end case that starts at a real host hold and ends at the drawn card, with no hand-built heldReplies:

Acceptance

1. core/test/: a terminal hold (noRetry: true) goes through the host's state/channel view, the test reads the Bot's heldReplies from that view and renders it, and asserts both that the view carries retry === false and that the drawn card offers no Retry.
2. Negative control on the same path: a retryable failure (no noRetry) still draws Retry — so the case cannot pass by dropping Retry everywhere.
3. Knife, and it must bite: remove retry: false from the view (the spread at channel.js:143, or the mapping in heldOf) → case 1 red. Today that knife is green, which is the defect this issue names.
4. The two suppression branches at channel.js:133 stay and are asserted through the same view read: a friend's chat (bot.remote) never carries heldReplies, and under enforcement a viewer who is not the Bot's owner sees none.
5. Mirrors and docs: patches/ds-bot regenerated with generate (the test file is mirrored), and docs/subsystems/core-host.md (the heldReplies paragraph) or core-client.md says the seam is covered — or Docs-not-needed: with a reason.

Out of scope

• Changing the rule itself (canRetry) or any Retry wording.
• The social plugin's own dock (plugins/social/client.js:1984 region): it reads the same predicate through __flybot__.canRetry and already has its own case.