feat(codex): add capability-aware collaboration mode and session state

[ashish200729]

Parent

Part of #7.

Summary

Add the Codex-specific collaboration-mode protocol and session state needed for a real Plan Mode. MonoCode currently maps Codex approval/sandbox settings from the shared RuntimeMode, but it has no separate collaboration-mode value and never asks the Codex app-server to run in Plan Mode.

This issue is the protocol/safety foundation. Keep the UI work and plan rendering changes in the follow-up issues.

Current implementation seam

• src/lib/harness/codex.ts owns thread/start, thread/resume, turn/start, turn/steer, and live Codex state.
• src/lib/harness/codexProtocol.ts builds thread/turn params and maps notifications, but currently only maps access/runtime settings.
• src/lib/session.ts has RuntimeMode values for access behavior; adding Plan Mode to that union would conflate two independent controls.
• src/lib/harness/registry.ts and the shared HarnessEvent types provide the adapter boundary.

Required behavior

1. Keep collaboration mode separate from access mode

Add a Codex-only typed mode with exactly these values:

• default
• plan

Store the selected mode on the session/workspace state independently from runtimeMode. Non-Codex sessions must remain unchanged and must not serialize a meaningless Codex mode.

The persisted default for old records and non-Codex sessions is default.

2. Use native Codex protocol support

Use the installed Codex app-server's native collaboration-mode/session-settings capability when available. The current upstream protocol exposes a collaboration mode and a thread/settings/update path; MonoCode must not assume that every locally installed Codex binary supports it.

Add a capability-aware adapter path that:

• detects support once per app-server connection/version;
• records whether native Plan Mode is supported, unsupported, or not yet known;
• applies the selected mode when starting or resuming a thread;
• updates the mode for future turns without starting an unintended turn;
• reuses the confirmed mode for subsequent turn/start calls;
• emits a useful typed error/status when the provider rejects the mode;
• never retries an unsupported field on every user turn.

If the protocol has multiple schema generations, keep the existing legacy thread/turn flow as the compatibility path. Do not invent a prompt-only fallback and label it Plan Mode: prompt instructions cannot guarantee that commands or file changes will not happen.

3. Make transitions explicit and serialized

Mode changes must be serialized with turns for one session:

• idle session: apply the new mode before the next turn;
• active turn: queue or disable the change until the turn reaches a terminal state;
• failed mode update: keep the previous local mode and show the error;
• reconnect/resume: re-establish the provider mode before accepting the next turn;
• stale responses from an older connection must not overwrite the current mode.

The existing access/runtime mapping must remain authoritative for approvals and sandbox policy. Switching to Plan Mode must not silently change Supervised, Auto-accept edits, Auto, or Full access.

Suggested implementation

• Add typed Codex mode/capability helpers in src/lib/harness/codexProtocol.ts.
• Extend the live Codex state in src/lib/harness/codex.ts with the negotiated capability and effective provider mode.
• Extend SendTurnInput or the Codex-specific adapter input without changing other providers unnecessarily.
• Add the minimal session/workspace persistence field and a backward-compatible sanitizer default.
• Treat provider mode confirmation as authoritative; do not optimistically label a failed transition as active.
• Preserve the current thread/start and thread/resume behavior for older Codex versions.

Acceptance criteria

• A supported Codex app-server receives a native Plan-mode selection before a Plan-mode turn.
• A supported Codex thread can switch back to Default for a later implementation turn.
• An unsupported app-server remains usable for ordinary Codex chat and reports Plan Mode as unavailable with an actionable explanation.
• Changing access mode still produces the same approval/sandbox payloads as before.
• Mode updates cannot race a turn or be applied to a different resumed session.
• Reloading/restoring a session preserves the selected mode; old session records safely load as Default.
• Unit tests cover supported/unsupported capability detection, start/resume payloads, settings-update success/failure, queued changes, stale responses, and legacy compatibility.
• npm run check:web passes.

Out of scope

• The Plan/Default picker and plan-to-implementation buttons.
• Reworking plan rendering or plan persistence de-duplication.
• Plan Mode for any provider other than Codex.
• Prompt-only emulation of read-only behavior.