feat(provider): evaluate Huawei MaaS as an Advanced Custom preset

[LIghtJUNction]

Upstream source

• QuantumNous/new-api PR: feat(relay): Add Huawei MaaS channel support QuantumNous/new-api#7239
• New commit this run: QuantumNous/new-api@5c699a3

The new commit materially expands the pending Huawei MaaS provider work: Claude Messages are now routed natively to /anthropic/v1/messages with x-api-key; Gemini and OpenAI Responses are converted to OpenAI Chat and sent to /openai/v1/chat/completions; response conversion is selected by the original client format. The PR also carries Huawei-specific embeddings/rerank/image generation/editing and /v2/models discovery.

api.lmm.best gap / overlap

There is no Huawei MaaS provider/preset in current main.

However, LMM already has a substantially more flexible Advanced Custom adaptor with per-route conversion, OpenAI/Claude/Gemini handling, Responses→Chat conversion, route-specific auth/header handling, model-list routes, images, embeddings and rerank. A large copy of the upstream Huawei adaptor would duplicate this machinery and increase provider-specific maintenance.

The remaining Huawei-specific parts to validate are mainly the preset/configuration contract:

• base URL https://api.modelarts-maas.com
• Chat: /openai/v1/chat/completions, Bearer auth
• Claude: /anthropic/v1/messages, x-api-key + default anthropic-version: 2023-06-01
• Gemini client requests: convert to OpenAI Chat
• Responses client requests: convert to OpenAI Chat and convert response back to Responses
• embeddings: /v1/embeddings
• rerank: /v1/rerank
• image generation + image edits: /v1/images/generations (JSON upstream, including edit conversion)
• model discovery: /v2/models

Recommended approach

Do not add a new provider enum/adaptor first. Try to express Huawei MaaS entirely as a built-in Advanced Custom preset/template. Add provider-specific code only for behavior that cannot be represented safely by Advanced Custom.

If a preset is sufficient, keep it declarative and reuse existing conversion/auth/response code. This is more consistent with LMM's goal of reducing provider-specific code and avoids copying upstream UI/branding.

Acceptance criteria

1. A Huawei MaaS channel can be created from a concise preset without manually entering every route.
2. OpenAI Chat works with Bearer auth and Huawei's /openai/v1/chat/completions path.
3. Claude /v1/messages stays native and uses x-api-key plus the default/forwarded anthropic-version header.
4. Gemini input converts to Chat and returns valid Gemini output.
5. OpenAI Responses input converts to Chat and returns a valid Responses payload for both streaming and non-streaming paths.
6. Embeddings, rerank, image generation and image edits use the documented Huawei routes and preserve LMM billing/usage accounting.
7. /v2/models discovery works through the existing management-route mechanism.
8. Tests cover route selection, auth differences, response conversion, and image-edit JSON conversion.
9. No regressions to pricing, model price locks, groups/fast, OAuth restrictions, provider selection, or the admin AI assistant.

Upstream #7239 is still open, so implementation should wait for its behavior to stabilize or be independently verified against Huawei MaaS before shipping.