feat: add MiniMax as an AI-coach provider - #54

What this does

Adds MiniMax as an AI-coach provider, alongside OpenAI, Gemini, and OpenRouter. It slots into the same provider-agnostic pattern already in the codebase (ResponsesClient + a per-provider Keychain store + the CoachClientResolver switch), so the rest of the coach is unchanged.

How it works

MiniMax speaks the OpenAI Chat Completions API, while this app speaks the OpenAI Responses API, so (exactly like OpenRouterClient / GeminiClient) the new MiniMaxClient is a translating adapter rather than a base-URL swap. It:

• maps the app's flat Responses function tools to Chat Completions' nested tools shape, and replays tool calls statefully across the agent loop (Chat Completions is stateless, so it accumulates messages per turn);
• strips MiniMax's inline <think>…</think> reasoning blocks from assistant content so the coach_response JSON parses cleanly;
• deliberately sends no response_format, cache_control, reasoning, or provider-routing block — none are documented for MiniMax's compat endpoint. Output shape is enforced by the injected promptInstruction system message plus the orchestrator's existing JSON-repair loop (same fallback path OpenRouter uses).

Endpoint: POST https://api.minimax.io/v1/chat/completions, Authorization: Bearer <key>.

Model selection (Settings)

When MiniMax is the active provider, the Model row shows the current MiniMax catalog (default MiniMax-M3; also M2.7 / M2.5 / M2.1 and their -highspeed variants, plus M2). The key is stored in its own Keychain service.

Web search

MiniMax's compat endpoint exposes no hosted web search (its web_search is an MCP-only tool that an iOS app can't call over plain HTTP). So the Web search toggle is hidden when MiniMax is active (and forced off on switch), and the hosted web_search spec is dropped in the adapter. All other tools (retrieval, charts, analysis, memory, actions) work normally.

Image input

Only MiniMax-M3 is multimodal, so the "Image input" toggle is shown only when M3 is selected and force-cleared if you switch to a text-only model.

Scope / wiring

• New: Coach/MiniMax/MiniMaxClient.swift, Coach/MiniMax/MiniMaxKeychainStore.swift
• Wired .userMiniMaxKey through CoachProviderMode, MiniMaxModel presets, CoachFeatureFlags (gate + status line), the three resolveClient sites (chat / summaries / notifications), SettingsView.coachTrailing, and CoachSettingsSection (provider option, model picker, key field).

Testing done

• Builds clean on an iOS simulator (app + widgets).
• New MiniMaxClientTests (6): endpoint/model, tool-call parsing, hosted web_search dropped, response_format/reasoning/provider omitted, <think> stripping, and the stateful continuation replay (assistant tool_calls message re-inserted before the tool result).
• Full PulseLoopTests suite passes (275 tests); existing OpenRouter suite still green.

⚠️ Needs live verification (I don't have a MiniMax key)

Everything above is compile- and unit-tested, but the wire protocol was built from MiniMax's docs and not exercised against a real key. Please confirm on device with a MiniMax key:

1. Auth — save a key; the coach Status should read Ready · MiniMax-M3. A 401 would mean a Bearer token alone isn't enough (e.g. a GroupId is required) — the docs say Bearer-only, but this is the first thing to check.
2. Tools + JSON — ask a data question (e.g. "how did I sleep this week"). This exercises function tool calls and confirms the model returns valid coach_response JSON even though response_format is omitted (prompt-instruction + JSON-repair only). This is the main behavioral risk.
3. No leaked reasoning — verify answers don't show raw <think>…</think> text.
4. Summaries + a check-in notification generate correctly.

Region note: the client uses the global host api.minimax.io. China-region accounts use api.minimaxi.com — there's a code comment at the endpoint marking where to flip it.