🤖 fix: acquire the event lock before the task-tree lock in task_send_message - #4161

Summary

task_send_message to a descendant task nested the task-tree lifecycle lock outside the workspace event lock, while reported-task cleanup nests them the other way (event lock held, then WorkspaceService.remove() takes the tree lock). When a send to a task interleaved with that task's cleanup, each side waited on the other's lock forever. The send path now acquires the event lock first, so every path that holds both locks uses one order, and a deterministic regression test pins the interleaving.

Fixes #4072

Background

Surfaced by Codex on #4058, which added the live recheck inside remove() and documented the inversion without changing it; the ordering predates that PR.

Implementation

• dispatchTrustedDescendantMessage now nests workspaceEventLocks.withLock(taskId, () => withTaskTreeLifecycleLock(taskId, ...)). The joint critical section is unchanged (both locks are still held for the whole body); only the acquisition order flips.
• This direction was chosen over deferring remove() out of the event-locked section because the event lock is the outermost lock everywhere else it appears: the stream-end, stream-abort and error listeners take it first, and cleanup rechecks, hard-timeout termination and workspace-turn finalization all nest inside it. Moving cleanup would have meant moving every tree-lock acquisition out from under handleStreamEnd.
• The workspaceEventLocks declaration now documents the order (event lock before task-tree lock) and the cleanup comment no longer describes an inversion.

Validation

• New test reported-task cleanup and task_send_message never deadlock on the event and task-tree locks: drives the real requestReportedTaskCleanupRecheck on a reported workflow-owned child, parks a sendMessageToDescendantAgentTask on its lock acquisition inside the window before the (lock-mirroring) remove() takes the tree lock, then lets removal proceed. Red on the previous nesting (Expected "settled", Received "deadlocked"), green after the swap; whole taskService.test.ts 490/490.
• Remote dogfood UAT at this SHA (Bun 1.3.5) reproduced the same red/green and full-suite results, and a real-model smoke confirmed task_send_message to a reported child reactivates it, to a live child queues, and stop-then-send reactivates, with no hang. The exact cleanup/send overlap window is covered by the deterministic test only; it is not observable by hand.

Risks

Low. The send path holds the same two locks over the same body; only which one it waits for first changes. Other tree-lock holders (create, stop, retitle, remove, archive, unarchive) never take the event lock, so the new order adds no wait edge.

Generated with xum • Model: anthropic:claude-fable-5-1 • Thinking: xhigh • Cost: $36.01