fix(slack,discord): drain mentions queued behind a continuation dispatch

[clsandoval]

Summary

dispatch_continuations_in_thread runs a continuation turn from outside a mention turn. It is called after a private form submission, and again at release when #233 re-runs a skipped dispatch. It adds the thread to _processing for the whole dispatch. A mention that arrives in that window goes down the normal queue path: it is appended to _pending and gets the ⌛ reaction. But the dispatch's finally only called _release_thread, which never drains _pending. So the mention kept its ⌛ and got no reply until someone mentioned the bot in that thread again. On Slack it also never received the "Sorry, something went wrong" notice. #233 sends more dispatches down this path, which makes the bug more likely.

An independent audit of the formal-verification PRs reported this (#236 review, finding (a)). I confirmed it with the failing tests below before changing any code.

The fix sends the end of the dispatch through the same drain the mention turn uses. The drain logic is shared, not copied:

• Slack: _orchestrate's drain loop moves unchanged into _drain_pending_mentions (one turn per author, per-author failure isolation), and its leftover apology moves into _notify_undrained_mentions. _orchestrate and dispatch_continuations_in_thread both call these two helpers. The dispatch drains before it releases the thread. If the dispatch raises, it apologises to anything still queued, the same way a failed mention turn does. dispatch_continuations_in_thread now takes team_id, which the drained turns need. The credential-form caller passes the workspace it already has, and the deferred re-run stores it with the other routing arguments.
• Discord: the dispatch calls the existing _drain_pending_mentions before _release_thread, on success and when the dispatch raises (then it re-raises for the spawned task's error log). This follows Discord's own drain-always contract in on_message, where a mention queued behind a failed turn still gets its turn; _drain_pending_mentions never raises. Slack apologises instead on its raise path, as its _orchestrate does. On both adapters a queued mention now gets either a turn or a notice, never a silent ⌛.

A drained turn runs without a per-tenant in-flight slot. This matches queued mentions behind a mention turn, which never take a slot of their own, and continuation turns, which take none either.

Formal model note: the ThreadQueue model in #236 cannot express this today, because FormDispatch there is atomic and never takes processing. Catching it needs a spec change: split the dispatch into a claim step and a release step. A release that does not drain then violates NoStrandedMention. Per the audit's run, that happens at 53 states with WithForm = TRUE: FormRecord, FormDispatch, 3 × Arrive, FormRelease.

Tests (red on main, green with the fix):

• slack/tests/test_continuation_dispatch_entry.py::test_mention_queued_during_a_continuation_dispatch_gets_its_own_turn: a real pending continuation is claimed by the real dispatch. During its continuation turn, a mention goes through the real _orchestrate, is queued, and gets ⌛. When the dispatch ends, that mention must get its own _run_thread_turn. Before the fix: AssertionError: the queued mention must get its own turn once the dispatch ends, got 0 turns. For this run only the team_id parameter was added, so the test could call the dispatch.

• discord/tests/test_mention_queue.py::test_mention_queued_during_a_continuation_dispatch_gets_its_own_turn: the same interleaving, with the mention going through the real on_message. Before the fix: AssertionError: the queued mention must get its own turn once the dispatch ends, got []. The ⌛ assertion before it passes.

• discord/tests/test_mention_queue.py::test_mention_queued_during_a_raising_continuation_dispatch_still_gets_its_turn: the dispatch raises after the mention queues. The mention must still get its own turn, and the error must still propagate. Before the second commit: AssertionError: the queued mention must get its own turn even when the dispatch raises, got [].

Existing Slack dispatch tests now pass team_id.

Checklist

• Tests added or updated for any behavior change
• uv run pytest passes locally (Slack adapter 677 passed; Discord adapter 1161 passed)
• uv run pyright passes locally (strict mode): 0 errors
• uv run ruff check . is clean
• uv run lint-imports passes (package boundary contracts)

🤖 Generated with Claude Code

[clsandoval]

Audit round 4 follow-up (requested change 1: a Discord dispatch that raises strands the queued mention).

Audit item → change

• Finding: on Discord, if dispatch_pending_continuations raised inside dispatch_continuations_in_thread, the finally released the thread without draining. The mention that queued during the dispatch kept its ⌛ with no reply or notice. Slack apologises on the same path.
• Change (418c4b3, packages/adapters/discord/daimon/adapters/discord/bot.py): the dispatch now drains _pending when the dispatch raises too, then re-raises so the spawned task still logs the error. Cancellation (shutdown) still skips the drain.
• Behaviour chosen: drain, not apologise. This is Discord's own drain-always contract. on_message drains a mention queued behind a failed turn (test_queued_followup_drains_even_when_originating_turn_fails), and _drain_pending_mentions never raises, so nothing is left over to apologise for. Slack keeps its apology, matching its _orchestrate. The invariant both adapters now share is that a queued mention gets either a turn or a notice, never a silent ⌛.

Fail before / pass after

• New test: discord/tests/test_mention_queue.py::test_mention_queued_during_a_raising_continuation_dispatch_still_gets_its_turn. A mention arrives through the real on_message during the dispatch and queues with ⌛, then the dispatch raises. The test asserts that the mention gets its own turn, that the RuntimeError propagates, and that _pending and _processing end up empty.
• Before the fix (head 88ef23b rebased onto main as a0c8aa8; bot.py is byte-identical between the two): AssertionError: the queued mention must get its own turn even when the dispatch raises, got [] at test_mention_queue.py:1024.
• After the fix: it passes.

Local checks (rebased onto main with #238; no conflicts): discord 1161 passed, slack 677 passed, ruff check/format --check clean, uv run pyright 0 errors, lint-imports 8 contracts kept. The CHANGELOG entry now says the mention gets its reply even when resuming the task fails.