Prevent duplicate chat submissions during asynchronous sends

[witbrock]

Merge decision: ready — repeated activation of an unchanged chat draft no longer creates duplicate active/queued work.

User outcome

Fixes native task #V#task_agent_837061ae33f7f4abdfb9c1539e833aa4. Concurrent sends could both await conversation creation, while image sends retained their caption and allowed a repeated click/Enter to enqueue it again.

Material changes

Claim the composer draft synchronously before asynchronous preparation, scoped to conversation and organisation generation. Keep the claim through an unchanged attachment draft; release it on draft edits/clearing and on completion or failure. Check it before interpreting a repeated composer event as steering. Explicit queue execution and server observation retain their existing paths.

Evidence

• Four regression cases fail on unchanged 9ac3d6681 and pass with the fix: concurrent session creation and repeated attachment sends, including edited/retyped follow-ups.
• Six targeted frontend suites: 95 passed, 3 existing failures. Baseline reproduces the same unrelated queue cancellation, off-session activity indicator and explicit workflow status refresh failures. Recovery, abort, drafts, steering and attachment tests otherwise pass.
• Chromium at 1440px and 375px: double-click plus Enter/repeated click produces one original queue record and one generation request; editing admits one follow-up. No page errors. Uses production markup/modules with synthetic HTTP, not live authentication or provider calls.
• Frontend static lint and git diff --check pass.
• Reusable browser regression: tests/browser/chatDuplicateSubmission.cjs; task-local logs/screenshots: .run/duplicate-send/.

Ship boundary

Minimum criteria are prevention of both reproduced duplicates and preservation of deliberate follow-ups and failed-send recovery. A candidate-caused lost draft, blocked retry or duplicate admission would stop shipment; none was observed. Existing baseline test failures are non-blocking. No backend policy, allowed-model UI, live state mutation or deployment is included.