🤖 fix: delegated-turn reservation is process-local, so unrelated admission can race across backend instances

[ThomasK33]

Problem

Unrelated-message admission (sendTreeMessage's delegatedRootUnavailable()) and task_list(scope:"instance") hide or refuse a root while it has a live or pending delegated workspace turn. Both read WorkspaceTurnManager.getLiveWorkspaceTurnRegistration(), which is a process-local map (activeWorkspaceTurnHandleByWorkspaceId), even though the handle record itself is durable.

With XUM_ALLOW_MULTIPLE_INSTANCES=1, a second backend does not see the reservation. It can therefore treat a consented root as idle and wake it while the first backend is dispatching a delegated turn. The owner's requireIdle send can then fail, or an uncorrelated peer turn can overlap the delegated execution.

This predates #4440. It affects any opted-in root that receives a delegated turn, including mode: "existing" follow-ups. #4440 makes it reachable for newly created delegated targets too, because they are now opted in by default.

Suggested direction

Have discovery and admission consult the durable handle store (or a cross-process lease) for active or pending workspace-turn reservations, not only the in-memory map.

Found by Codex on #4440 (thread on workspaceTurnManager.ts grantDefaultUnrelatedWorkspaceConsent); deferred there as a pre-existing multi-instance defect.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[linear-code]

MUX-200

[ThomasK33]

Also related: #4440 added a process-local pending deferred-default marker (pendingDefaultUnrelatedConsent in workspaceService.ts). An explicit opt-out handled by a second backend during delegated workspace creation cannot cancel it. Note that this part is introduced by #4440 (the second backend is only the trigger), so it should be fixed with the #4440 follow-up design rather than treated as pre-existing.