fix: add more fields to ThreadStartResponse and ThreadResumeResponse

[bolinfest]

This adds the following fields to ThreadStartResponse and ThreadResumeResponse:

    pub model: String,
    pub model_provider: String,
    pub cwd: PathBuf,
    pub approval_policy: AskForApproval,
    pub sandbox: SandboxPolicy,
    pub reasoning_effort: Option<ReasoningEffort>,

This is important because these fields are optional in ThreadStartParams and ThreadResumeParams, so the caller needs to be able to determine what values were ultimately used to start/resume the conversation. (Though note that any of these could be changed later between turns in the conversation.)

Though to get this information reliably, it must be read from the internal SessionConfiguredEvent that is created in response to the start of a conversation. Because SessionConfiguredEvent (as defined in codex-rs/protocol/src/protocol.rs) did not have all of these fields, a number of them had to be added as part of this PR.

Because SessionConfiguredEvent is referenced in many tests, test instances of SessionConfiguredEvent had to be updated, as well, which is why this PR touches so many files.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

ThreadResumeResponse uses stale provider/cwd values

When resuming a thread, the response populates model_provider and cwd from the pre‑existing rollout summary rather than from the configuration used to spawn the resumed session. If the caller passes overrides in ThreadResumeParams (e.g. switching providers or changing working directory), the new session will run with the overridden values but the API will still return the old values stored in the rollout, so clients cannot reliably determine the effective configuration after a resume. Consider sourcing these fields from session_configured or the derived config instead of summary so the response reflects the actual session settings.

Useful? React with 👍 / 👎.