JVNAUTOSCI-2690: Make direct-message sends prompt and idempotent

[witbrock]

Merge decision: ready — direct-message sends now give immediate pending feedback, converge to one durable effect across retries, and remain bound to the actor-owned tab organisation.

User outcome

A user can send or retry a reply or new direct message without an inert-looking UI, accidental duplicate delivery, or cross-tab organisation leakage. This repairs the real Messages incident documented in JVNAUTOSCI-2690.

Material changes

• Removes cold shared-workflow-registry construction from ordinary message text writes, using cached or exact represented workflow identity reads instead.
• Adds sender-scoped REST idempotency with deterministic server-owned Mongo identity, exact replay receipts, changed-payload conflicts, and an optional defensive index.
• Resolves supplied window selectors strictly for organisation-scoped sends while preserving explicit membership-authorised organisation recovery and legacy no-window clients.
• Makes both compose surfaces single-flight and visibly pending; persists exact per-tab draft, actor/window scope, delivery scope, recovery organisation, and retry key across ambiguity/reload; guards pending cancellation.
• Adds focused backend, concurrency, multi-org, frontend lifecycle, and index tests.

Jira: https://naoinstitute.atlassian.net/browse/JVNAUTOSCI-2690

Evidence

• 145 affected backend tests passed, including a forced concurrent no-custom-index race.
• 23 Messages frontend tests passed.
• Fatal Ruff checks, frontend static lint, Node syntax, and diff checks passed.
• Isolated authenticated AgentTest browser replay showed Sending… and disabled/busy controls at 180 ms, overlapping-send suppression, pending New message Close/Cancel lock, and successful clearing.
• Canonical actor-authorised read-back found one durable message for each unique marker, exact retry returned the same message ID, changed payload returned 409, and a never-bound window selector returned 409 with zero writes.
• Live sends completed in 4.6–6.3 s versus 61.5–72.0 s in the incident; zero /von/generate requests and no real-user messages occurred.
• Independent final review found no material blocker.

Ship boundary

• Minimum ship criteria: immediate pending UI; one durable actor-scoped effect for concurrent/exact retries; changed-intent conflict; strict selected-tab organisation binding; visible reload-safe retry state for reply and New message.
• Stop-ship conditions: duplicate durable effects, fallback from a supplied stale/foreign tab selector to browser-wide organisation, cold registry construction on the message write path, or loss of the exact draft/delivery scope/key after an ambiguous result.
• Non-blocking observations: the accepted Atlas-backed send remains above the generic one-second slow-request threshold, but is observable, completes in seconds, and no longer performs the minute-long cold registry build.
• Non-goals: deployment/activation, general chat prompt-queue architecture, event-workflow fan-out, or broad Messages read-path optimisation.