fix: answer a repeated verbatim done with its stored receipt

[cgaravitoq]

A verbatim done milestone moves its task to done in the same request that posts it, so the task token died before its own milestone could be retried: a runner whose answer was lost re-posted the same deterministic id and met 401 unauthorized, then reported an outcome the delegation route refuses. A done task's token now authorizes only the milestone whose posted receipt it wrote, so the retry settles on that receipt (200 {"ok": true, "ts": "172.1"}) without a Slack call; a new id, another task's receipt and GET /progress/replies keep 401.

The last-resort narrated fallback also ran after store.complete had posted the receipt and moved the task, erasing the ts the thread already has and telling the retry the milestone was never posted; it now writes only while the receipt is still in flight.

Verify

• Re-posting the same done body after done answers 200 {"ok": true, "ts": "172.1"} with no new Slack call: a repeated verbatim done answers its stored receipt and no new milestone passes the dead token asserts the stored receipt, an unchanged chat.postMessage count and an unchanged total Slack call count. Red on f28de36 (Expected: 200 / Received: 401 at the second post), green after.
• A new id after done still 401: same test, {"error": "unauthorized", "ok": false} for done-2, with no receipt row for it and no Slack call. It is a guard, green before and after.
• Another task's posted receipt stays 401: another task's posted receipt stays unauthorized once its task is done (two tasks, both done, the second task's token replaying the first's milestone id). Dropping task_id = delegation_tasks.id from the replay lookup turns its answer into 403 token_scope, so the binding is what the test pins.
• The conductor's patch test (posted receipt kept after failing completion): a verbatim done whose completion keeps failing after the commit keeps its posted receipt, applied as the first test next to a verbatim done whose first completion pass fails after the commit still finishes the task. Red on f28de36: the receipt came back {"state": "narrated", "ts": null} where the batch had stored posted 172.1; green after.
• complete() twice converges: running the done completion twice converges on one posted receipt and one done task runs the completion three times (the replay, then a direct store.complete with a different ts) and asserts one posted receipt holding the ts the first completion stored, one done task, no second Slack call. Red on f28de36 (the second post 401), green after.
• bun run verify: exit 0, 376 pass / 0 fail across 17 files, format, lint, typecheck, knip, deploy:dry and bun audit (561 packages, 1 ignored) green.

Commits

1. test f244b81: pins the replay, the dead-token refusals and the kept receipt.
2. fix dcb1b2b: the completedTask authorization, the receipt's task binding and the in-flight guard on the narrated fallback.

Migration

0010_progress_receipts_task.sql adds progress_receipts.task_id because the replay must know which task a posted receipt belongs to, and the receipt stored no such binding: without it a done task's token could replay any posted receipt, since a milestone id alone does not say who wrote it. delegation.store.complete writes it in the same batch that moves the task to done, so a posted receipt carrying a task binding implies the task is done by that token.

Not covered

• The live run: proving this against a real runner is the conductor's wave-end pass.
• POST /progress now parses the body before it authorizes, so a malformed body with a dead token answers 400 invalid_request where it answered 401: the milestone id decides whether a done token may replay and the body is the only place it appears. No store or Slack call happens before either refusal.
• The narrated fallback is unchanged for a milestone whose completion never committed: it still settles the in-flight receipt so a retry cannot post the milestone twice.

Goal: bloop-delegation-3 row A1.