fix(llm): add MiniMax global provider

[moutayam]

Description

Fixes #759.

The built-in MiniMax provider currently uses the China endpoint, which rejects
keys created on the MiniMax Global platform. MiniMax Global and China use
separate account spaces and API key systems.

This change:

• Makes minimax use https://api.minimax.io/v1 with MINIMAX_GLOBAL_API_KEY
• Keeps minimax-cn on https://api.minimaxi.com/v1 with MINIMAX_API_KEY
• Updates the provider registry and resolver fallback tests to lock the separate keyspaces
• Updates localized documentation
• Keeps the VS Code provider mirror aligned with the CLI registry so
  minimax-cn is selectable in the official provider picker

Existing China-key users currently configured with minimax must select
minimax-cn.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• Breaking change (existing China-key users configured with minimax must select minimax-cn)
• New feature (non-breaking change that adds functionality)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• make check passes locally
• make test passes locally
• make build passes locally
• Manual testing

Manual testing:

• Configured the minimax preset with a valid MiniMax Global API key
• Ran ocr llm test
• Confirmed the request succeeded against the MiniMax Global endpoint

Checklist

• My code follows the project's coding style (go fmt, go vet)
• I have performed a self-review of the code
• I have added or updated tests covering the provider registry
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly
• I have signed the CLA

Related Issues

Closes #759

[CLAassistant]

All committers have signed the CLA.

[wu21-web]

Suggested change

	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_API_KEY` |
	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_CN_API_KEY` |

[wu21-web]

Since you named the CN API as "Minimax CN API" in the API desc, maybe you can distinguish it further.

[wu21-web]

Suggested change

	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_API_KEY` |
	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_CN_API_KEY` |

[wu21-web]

Ditto

[wu21-web]

Suggested change

	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_API_KEY` |
	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_CN_API_KEY` |

[wu21-web]

Suggested change

	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_API_KEY` |
	| `minimax-cn` | openai | `https://api.minimaxi.com/v1` | `MINIMAX_CN_API_KEY` |

[lizhengfeng101]

@moutayam Thanks for putting this together — clean PR and nice that you covered all four localized docs too.

One suggestion on the env var: right now both minimax and minimax-cn share MINIMAX_API_KEY, but since Global and China use separate key systems (as you noted), it'd be better to give the new global variant its own env var — something like MINIMAX_GLOBAL_API_KEY — and let minimax-cn keep the original MINIMAX_API_KEY.

This has a couple of benefits:

1. No env var collision — users can configure both providers independently if needed, which is consistent with how we handle dashscope / dashscope-tokenplan and z-ai / z-ai-coding.
2. Softer migration — existing China-key users won't accidentally send their key to the global endpoint. Instead of a confusing auth failure, they'd get a clear "no API key configured" error on minimax, and switching to minimax-cn would just work with their existing MINIMAX_API_KEY.

What do you think?

[moutayam]

Thanks, agreed. I’ll update the Global preset to use MINIMAX_GLOBAL_API_KEY and keep MINIMAX_API_KEY for minimax-cn, consistently across the Go registry, VS Code provider mirror, documentation, and tests. One migration detail: saved credentials under providers.minimax.api_key take precedence over environment-variable fallback, so users with a saved China key under minimax still need to switch explicitly to minimax-cn. The environment-variable split prevents collisions for environment-variable-based configuration.

[wu21-web]

Thanks for the update, you have successfully dealt with the 2 clashing vars.
I just doubt if writing a single test only for MiniMax is necessary.

[wu21-web]

Other parts look fine.

[moutayam]

Fair point. The resolver tests already check both MiniMax URLs and the two env-var fallbacks, so the separate registry test may be overkill. I can remove it and keep the resolver coverage if you’d prefer.

[lizhengfeng101]

LGTM