Plugins cannot fence new sends while atomically stopping and changing thread routing

[Danielalnajjar]

Attempted workflow

A plugin needs to stop an idle thread, change durable routing or account state, and then let future sends resume on the new route.

Actual result

Send and stop are independent server routes with no shared thread-scoped lease. A plugin can preflight status, stop the runtime, reread queued messages, and mutate routing, but a user, automation, or queued-message sender can still start a turn after the final read and before routing commits.

Evidence:

• packages/server-contract/src/public-api.ts:979-993,1091-1096 exposes send and stop independently.
• apps/server/src/routes/threads/actions.ts:319-343 can queue or start a send without a routing-mutation fence.
• apps/server/src/routes/threads/actions.ts:492-502 and apps/server/src/services/threads/thread-lifecycle.ts:1473-1530 stop separately and only settle that request's runtime.

Expected result

BB exposes a general server-owned thread mutation fence. Once acquired, no user send, queued-message auto-send, automation send, or other turn-start path begins until routing mutation commits and the fence releases.

Acceptance criteria

• Sends arriving while fenced have one stable behavior: reject with a conflict or queue without starting.
• Release is guaranteed on success, callback failure, caller disconnect, and bounded expiry.
• Concurrency tests cover sends before stop settles, after stop but before mutation, and concurrently with release.
• The primitive remains policy-neutral and does not encode subscription-picker behavior.

AGENT GENERATED: by GPT-5.6 Sol