[Feature] Allow ChatGPT model/engine selection in session mode (e.g. instant vs thinking)

[ch0udry]

Problem
When using ChatGPT through Proxima's session (browser) mode, there is no way to choose which ChatGPT model answers. The engine hardcodes model: 'auto' in the request payload to chatgpt.com's internal API (electron/providers/engines/chatgpt-engine.js, payload built around line 453):

var payload = {
    ...
    model: 'auto',   // hardcoded
    ...
};

With 'auto', OpenAI's own router decides per-message whether to use the instant model or a thinking/reasoning model. In practice this means most prompts get answered by the fast instant model, and users cannot force a thinking model for complex tasks (architecture design, deep research, hard debugging) — nor pick a specific model their plan offers.

Neither ask_chatgpt nor new_conversation (MCP tools) expose any model parameter, and while ask_model accepts a model field, it is ignored by the ChatGPT session engine (it only works for Gemini engines like gemini:3.1-pro / gemini:3.5-flash).

Proposed solution

1. Add an optional model parameter to the ChatGPT session path (MCP ask_chatgpt, REST /v1/chat/completions, and CLI proxima ask chatgpt --model), e.g.:

   proxima ask chatgpt "design a saga orchestrator" --model thinking

   { "model": "chatgpt:thinking", "message": "..." }

2. Map user-friendly engine names (auto, instant, thinking, or explicit model slugs) to the corresponding value in the internal API payload instead of hardcoding 'auto', keeping 'auto' as the default for backward compatibility.
3. Surface available ChatGPT models/engines in GET /v1/models and proxima models, the same way Gemini engines (3.5-flash, 3.1-pro, 3.1-flash-lite, gemini:auto) are already listed.

Alternatives considered

• BYOK with an OpenAI API key: works, but defeats the purpose of free session mode for users without API keys.
• Prompt engineering to nudge the Auto router toward thinking: unreliable, no guarantee.
• Manually patching model: 'auto' in the engine locally: fragile, lost on updates, and model slugs change.

Additional context

• Gemini session mode already demonstrates the pattern: engine selection via provider:engine syntax (electron/providers/api.cjs parses parts[1] as engine) and engines listed in /v1/models.
• Claude/Perplexity session engines likely have the same limitation, so a generic per-provider engine mechanism would be ideal.
• Observed behavior: a long research prompt routed to the instant model and answered in ~140s via Auto; users wanting deeper reasoning have no switch.