fix(codex-acp): resume sessions with their recorded model

[jsgrrchg]

Summary

Resuming a Codex chat (session/resume / session/load) could silently switch it to a different model and post this message in the chat:

This session was recorded with model X but is resuming with Y. Consider switching back to X as it may affect Codex performance.

Root cause

• restore_session in vendor/codex-acp/src/codex_agent.rs built the resume config from the agent's global default (build_session_config(&self.config, …)). It never used the model the thread was recorded with.
• On resume, codex-core compares the last recorded model with the current one and emits an EventMsg::Warning when they differ (core/src/session/mod.rs).
• The ACP forwards warnings to the client as agent text (thread.rs), so the notice appeared as an assistant message.
• The desktop app's native resume path trusts the model the runtime reports, so the chat stayed on the default model.

Fix

Before resuming, apply the model and reasoning effort stored in the thread metadata (StoredThread, which restore_session already reads). This mirrors what the Codex app-server does in merge_persisted_resume_metadata. The thread resumes on its recorded model, so codex-core has no mismatch and emits no warning.

The configured defaults are kept in these cases:

• No model is stored for the thread (e.g. no SQLite metadata).
• The thread was recorded under a different model provider. Switching providers would also require swapping the provider info.
• No reasoning effort is stored. The configured effort is kept.

Changing the model afterwards through set_config_option works as before. That path does not trigger the warning.

Testing

• New unit test resume_restores_model_recorded_under_the_configured_provider.
• Ran the full codex-acp lib suite (112 tests) and cargo clippy --all-targets with no warnings, via apps/desktop/scripts/run-with-codex-v8.mjs --target x86_64-unknown-linux-gnu -- cargo ….