fix: persist ACP session config in Codex threads

[gilbertl]

Summary

• persist mode, model, and reasoning-effort changes immediately with thread/settings/update
• restore the ACP agent mode from Codex approval and sandbox settings on session resume/load
• apply mode changes to in-memory session state before persistence completes
• resolve the current mode after asynchronous prompt preparation so a resumed first turn cannot overwrite full access with a stale Agent snapshot
• return the legacy sessionId field from session/load so persistent ACP clients can retain the loaded Codex thread

Why

Session config was split between adapter memory and Codex thread state. Reasoning effort could revert after one turn, and agent mode could revert when the ACP worker restarted. AoE also restores Agent (full access) asynchronously after session/load, which exposed a second race: a queued first prompt could capture Agent mode, pause during skill refresh, then start with on-request approval even though full access had already been restored.

Codex 0.145 supports model, effort, approval policy, and sandbox policy in thread/settings/update. Persisting those values makes the Codex thread authoritative. Reading them back on resume restores the ACP picker state, and resolving the mode immediately before turn/start prevents stale prompt-preparation snapshots.

The legacy sessionId response is required by persistent ACP clients that validate session/new and session/load uniformly and cache the returned thread identifier for the next worker restart.

Fixes #336.

Test plan

• npm test: 332 passed, 28 skipped
• npm run typecheck
• npm run build
• focused regression: prompt starts and pauses in skill refresh, full access is applied, then turn/start uses approvalPolicy never and dangerFullAccess
• real AoE cold-resume E2E with a disposable Codex structured-view session: queue the first prompt during worker session/load, execute a write outside the workspace, observe zero ApprovalRequested events, and confirm the Codex turn_context records approval_policy never with danger-full-access