[bamboo] fix: bind Root chat admission to mode authority revision

[bigduu]

Part of #791. Follow-up to #1327 and the Lotus Next #197 mode-only migration.

Current boundary

A mode-only ACK and a later ordinary POST /chat are two requests. Another client can change Root mode between them; a Session detail GET does not lock the user's next message to the acknowledged mode. Another change between chat admission and model/tool execution may also alter effective tool authority.

Acceptance slice

Let a Root chat explicitly require the mode authority version it was composed against, then either admit and execute under a documented consistent authority or reject without admitting the message.

Acceptance criteria

• An optional expected Root birth token and mode/authority revision is checked at the same durable admission commit as the user message. A stale or recreated Session yields a typed conflict with zero new user messages and zero model turns.
• A successfully admitted turn has a deterministic execution authority boundary: either its selected mode is pinned for that turn, or a subsequent conflicting mode change aborts before execution. No stale snapshot may widen the orchestration-only tool allowlist.
• Ordinary chat requests that omit the expected version preserve existing persisted-selection behavior.
• Barriers cover mode ACK -> chat admission, chat admission -> execution, two AppStates sharing storage, late requests, and restart. Tests prove the rejected request has no message or run side effect.

Scope and estimate

Existing-Root chat admission/version contract and focused runtime tests, 4–8 hours. If admission and execution-start require independent persistence/recovery protocols, split into linked Issues before expanding the patch.

Non-goals

Mode-only terminal recovery (#1327), first-chat Session creation (#1332), Lotus Next UI wiring, generic chat replay, and remote Actor placement.

Implement and review in a focused local branch/worktree. Use local review only, with no GitHub PR review gate.