Fix the question-response handler: double dispatch, non-atomic write, inverted ordering

[TheGreatAxios]

Summary

CL-7192: three defects in the question-response handler (POST /workbenches/:id/messages/:id/blocks/:id/responses), the route that records a user's answer to a question card.

• Double dispatch — every successful upsert unconditionally sent the answer into the workbench and dispatched a turn, so a changed answer or a double-click that beat the UI's disable ran a second turn. Gated the send behind a new claimBlockResponseNotification guard (a token-scoped, guarded UPDATE ... WHERE notified_at IS NULL): only the submission that wins the claim ever sends and dispatches. Once a question is claimed, a later changed answer still upserts the new payload but can never re-claim/re-notify — permanently, not just within a race window.
• Non-atomic write — the upsert committed before the send; a thrown send left the row reading "answered" with the agent never notified. A failed send now releases the claim and returns an explicit notify_failed 500 telling the caller their answer was saved and to retry, rather than a silent row/timeline mismatch. True cross-system atomicity (one DB row, one external send) isn't achievable without an outbox; this makes the failure recoverable and disclosed instead.
• Inverted ordering — the turn was dispatched before the machine-readable block.response event was posted, so the agent could read the timeline before its own correlation event existed. The event (built from the upsert's own returned row, not the request's local payload) is now posted before the question branch ever gets a chance to dispatch.

Design notes

• claimBlockResponseNotification/releaseBlockResponseNotification are token-scoped (notification_claim_token, migration 0026) the same way turn-claims.ts is for CL-7129 — but this is defensive insurance for a future release call site, not a fix for a reachable bug today: this store has no TTL/reaper, so nothing can reassign a claim out from under its own holder yet. write-claims.ts's own release is unconditional for the same reason.
• Deliberately did not consolidate with write-claims.ts or turn-claims.ts in this PR, to keep the diff scoped and avoid collision with other lanes touching this package. If ever generalized, write-claims.ts's shape (no TTL) is the closer match.
• Added packages/chat/test/block-responses.drizzle.test.ts (DB-gated, mirrors write-claims.drizzle.test.ts) proving the guarded UPDATE is race-safe against a real Postgres connection pool, not just single-threaded in-memory JS.

Known follow-up (not in this PR)

Filed CL-7245: the chat-ui question-block component gives no retry affordance once a question renders "answered" after a notify_failed response — the release-on-failure claim design depends on a client retry the current UI can't trigger. Out of scope here (packages/chat only).

Test plan

• cd packages/chat && bun run typecheck && bun test — 732 pass, 43 skip (DB-gated, no local DATABASE_URL), 0 fail
• bunx prettier --check on all touched files
• Each commit individually typechecks and passes tests (verified via per-commit checkout)
• Reviewed by Greybeard (approach) and Critique (implementation) before push
• CI (pending)

DO NOT MERGE — for review only.