docs(acceptance): plan the mecatui in-app yolo toggle (Plan / Interface)

[jtenniswood]

Stage: Plan / Interface (Split delivery)

Relates to #2057. This PR adds only the acceptance plan and does not close the issue.

Summary

Adds docs/acceptance/mecatui-yolo-toggle.md, the behavioral and interface contract for switching into and out of yolo from inside mecatui:

• /yolo (embedded mecatui only) asks for confirmation with a distinct y key. It then quits the TUI and rebuilds the embedded server at posture yolo, resuming the same session. Running /yolo again returns to the posture this process launched with.
• Posture stays per-Build. The switch is a relaunch, the same as quitting and relaunching with --posture plus --resume. It reuses the existing ConnectRestartIntent quit-with-intent pattern, and nothing changes in composition, the permission fold, or the wire.
• Remembered per workspace. If you quit while in yolo, the next launch in that workspace starts in yolo with a fresh session. Turning it off clears the remembered state. An explicit --posture flag wins for that launch. mecatui connect ignores the state, and a privileged launch outside a sandbox ignores it with a warning.
• Refusals:
  • not offered under connect or in debug sessions;
  • refused mid-run or while an approval is pending;
  • refused when privileged outside a sandbox;
  • refused under --no-store;
  • refused while the session is on a sibling worktree.
• Security: /yolo is a registered builtin, so it never reaches the model or expands a project command. The startup trust prompt is not asked again on a relaunch. Turning yolo off drops the project trust that came only from posture.

Work classification: Bounded, no new ADR. Every human decision is recorded in the plan, and its status is proposed.

Review focus

• The seven interface-contract categories, especially CLI / config, Events / persistence (the new $XDG_STATE_HOME/mecatui/posture.yaml), and Security / authority.
• Whether remembering yolo per workspace (a new operator-tier posture input in the user's own state directory) is still Bounded, or needs an ADR.

Verification

• bash .claude/skills/to-acceptance-plan/scripts/check-acceptance-plan.sh docs/acceptance/mecatui-yolo-toggle.md: passed. The only warning is the advisory one about having no TestADR_*/TestInvariant_* names; the scenario tests use TestMecatuiYoloToggle_Scenario<N>_*.
• task docs: passed (matlatl strict: 0 broken links, orphans, or unreachable pages).
• One advisory devils-advocate pass ran. Its findings are folded in: the trust prompt on relaunch, explicit-trust preservation, worktree reattach, rebuild failure, builtin interception, confirm-key specificity, relaunch recursion, and the restore-posture source.

Merging this PR approves the plan. Implementation follows via /plan-orchestrate.

[aponcedeleonch]

This sounds very similar to: #1730
with implementation: #1935