ChatGPT Codex: add GPT-6 Astra with distinct xhigh/max reasoning support

**What problem would this solve?**

Add first-class `gpt-6-astra` support to the **ChatGPT Codex subscription provider** (`chatgpt_codex`), with every native reasoning effort selectable independently. Also correct GPT-5.6 Sol's missing native `max` support.

The Codex catalog omits Astra and caps Sol at `xhigh`. Goose also collapses `xhigh` and `max` into one ThinkingEffort value, so a catalog-only change or changing Max's mapping would not preserve both choices.

Source inspected at [846cbeaf](https://github.com/aaif-goose/goose/tree/846cbeaf5157f9be8a22aec93bd2ba9c5ddad983):
- [Codex effort mapping](https://github.com/aaif-goose/goose/blob/846cbeaf5157f9be8a22aec93bd2ba9c5ddad983/crates/goose/src/providers/chatgpt_codex.rs#L237-L263): Max becomes xhigh.
- [Shared effort parsing](https://github.com/aaif-goose/goose/blob/846cbeaf5157f9be8a22aec93bd2ba9c5ddad983/crates/goose-provider-types/src/thinking.rs#L305-L336): max and xhigh are aliases.
- [Suffix normalization](https://github.com/aaif-goose/goose/blob/846cbeaf5157f9be8a22aec93bd2ba9c5ddad983/crates/goose-provider-types/src/model.rs#L301-L329): -xhigh loses its identity; -max is not recognized.

**What would a good outcome look like?**

- Astra appears in the ChatGPT Codex model inventory.
- CLI and Desktop expose **low, medium, high, xhigh, max** for Astra, with the exact selected value sent as `reasoning.effort`.
- XHigh and Max remain distinct through model suffixes, explicit settings, session persistence/resume, and model switching.
- Internal Off requests (e.g. session naming) use Astra's lowest supported effort, not unsupported `none`; the UI does not imply Astra can disable reasoning.
- Sol can request native max, while older models and unrelated providers retain supported fallback behavior.
- Astra's context accounting reflects the Codex surface, respects explicit overrides, and does not blindly inherit the API's 1.05M-token window.

**Possible approaches**

Introduce a distinct XHigh representation, update suffix parsing and exhaustive provider mappings, and make selectors model-aware. Keep existing provider/model defaults unchanged. Historical xhigh selections already persisted as max cannot be reconstructed reliably. Document that Max on these newly supported models will request native max rather than xhigh.

**Proposed verification:** exact payloads for all five efforts; suffix stripping and explicit-setting precedence; serialization/resume/model switching; internal Off handling; inventory and context-limit override precedence; CLI/ACP/Desktop choices; and regressions for existing provider mappings. Run affected Rust/frontend tests and lint checks. If shared agent behavior changes, verify both agent-loop paths. Test live account eligibility/backend acceptance separately from deterministic serialization checks.

**Additional context**

- [OpenAI Astra documentation](https://developers.openai.com/api/docs/models/gpt-6-astra) lists low through max, with no none; [Sol documentation](https://developers.openai.com/api/docs/models/gpt-5.6-sol) also lists max. [Codex model documentation](https://developers.openai.com/codex/models) lists Astra.
- OpenAI's [pinned Codex catalog](https://github.com/openai/codex/blob/e3a52b87b28760413eafa340e2ab23d653f0bbe7/codex-rs/models-manager/models.json) lists those five efforts for Astra/Sol. Astra has a 272,000 default context profile and 872,000 maximum profile; these are client metadata, not independently verified account limits.
- The catalog also advertises Ultra, but its [ordinary-request normalization](https://github.com/openai/codex/blob/e3a52b87b28760413eafa340e2ab23d653f0bbe7/codex-rs/protocol/src/openai_models/reasoning_effort.rs) maps it to a native effort. **Ultra multi-agent orchestration, Fast processing, Pro mode, and authentication changes are out of scope.**
- Related: #11949 reports Astra legacy-API routing; this proposal specifically covers subscription-provider discovery and complete effort selection. The inspected ChatGPT Codex provider already posts to its Responses endpoint. #11869 and #11976 address API/Databricks support and Astra Off handling, not this complete Codex path. Fast processing is tracked separately in #11910.
- This report is based on source inspection and official documentation, not live Astra requests through Goose. No implementation has begun.

- [x] I have checked existing issues/PRs; related work is linked above, with the distinct scope explained.

Please confirm the scope and verification plan for implementation. Do not begin implementation until this issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1), unless maintainer-directed.