feat(provider): evaluate a native StepFun preset without duplicating Advanced Custom routing

[LIghtJUNction]

Upstream

• PR: feat: add StepFun channel with native chat/messages/responses relay QuantumNous/new-api#7525
• Head: QuantumNous/new-api@f773df7
• Related upstream issue: [功能请求] 新增 StepFun（阶跃星辰）渠道适配 QuantumNous/new-api#7526

Upstream adds a dedicated StepFun channel type with default base URL https://api.stepfun.com, a provider adaptor for native /v1/chat/completions, /v1/messages, and /v1/responses, a built-in model list, model discovery, icon metadata, tests, and i18n.

LMM gap / current behavior

Current main@1b3eb3828f958f4f0a393c8ec4335efa9e1af8d5 has no StepFun channel/API type or dedicated adaptor.

However, this is not currently a protocol blocker in LMM: Advanced Custom already supports native OpenAI Chat, Claude Messages, and OpenAI Responses routes, Bearer auth, provider model-list routes, and is already included in the frontend's model-fetchable channel types. A StepFun deployment can therefore be represented today without adding a permanent provider enum.

This makes the upstream change primarily a provider preset / UX improvement for LMM rather than an urgent compatibility fix.

Why not port #7525 directly yet

1. The upstream PR is still open and has only one provider-specific implementation commit. There is no maintainer merge/review signal yet.
2. StepFun Responses support is model-dependent: upstream verification reports step-5-preview works while step-3.5-flash is rejected by the provider. LMM should not advertise /v1/responses as uniformly supported by every built-in StepFun model.
3. LMM's channel numbering and relay architecture have diverged from upstream (OpenHuman occupies type 61; LMM does not currently mirror upstream TaskPlugin/vLLM/SGLang channel types). Do not blindly copy enum/API-type assumptions.
4. LMM already has Advanced Custom; adding a dedicated adaptor that only pass-throughs three native protocols risks duplicating routing/auth/model-list logic that LMM intentionally centralized.
5. The provider model list is fast-moving. A hard-coded 14-model list would become another maintenance surface unless treated only as a seed/fallback and reconciled with GET /v1/models.

Suggested LMM-native approach

If upstream #7525 is merged and remains stable, prefer a thin StepFun preset on top of existing generic routing instead of a large duplicated adaptor:

• preserve a stable dedicated channel identity only if it materially improves operator UX;
• default base URL to https://api.stepfun.com;
• map Chat -> /v1/chat/completions, Claude -> /v1/messages, Responses -> /v1/responses using the existing Advanced Custom/native-response machinery where possible;
• use standard Authorization: Bearer <key>;
• fetch /v1/models dynamically; keep any bundled model list as fallback only;
• reuse existing OpenAI/Claude response handlers and LMM billing/logging paths;
• do not touch pricing/group/model-price-lock/fast/OAuth/admin-AI-assistant behavior;
• explicitly gate or document model-level Responses support rather than treating the whole provider as Responses-capable.

If a dedicated adaptor is still cleaner after upstream settles, keep it small and implement it through LMM's relay/channel/factory rather than copying upstream's now-different registration layout verbatim.

Files / areas to compare when implementing

Upstream:

• constant/channel.go
• constant/api_type.go
• common/api_type.go
• relay/channel/stepfun/{adaptor.go,constants.go,adaptor_test.go}
• relay/relay_adaptor.go
• web/src/features/channels/{constants.ts,lib/channel-utils.ts}
• i18n/static keys

LMM:

• apps/api-go/constant/channel.go
• apps/api-go/constant/api_type.go
• apps/api-go/common/api_type.go
• apps/api-go/relay/channel/factory/factory.go
• apps/api-go/relay/channel/advancedcustom/adaptor.go
• apps/web/src/features/channels/constants.ts
• apps/web/src/features/channels/lib/channel-utils.ts

Acceptance criteria

• A StepFun channel can be configured from the UI without hand-writing unrelated provider settings.
• GET /v1/models discovery works and does not rely solely on a stale bundled list.
• Chat Completions non-stream + stream route to StepFun and preserve existing LMM usage/billing behavior.
• Claude Messages non-stream + stream route natively and preserve LMM response/error handling.
• Responses non-stream + stream work for a provider-confirmed supported model; an unsupported model returns the provider error without charging a failed request.
• Existing Advanced Custom behavior remains unchanged.
• No channel-number collision with LMM-specific types and no regression to price locks, groups, /fast, OAuth restrictions, or the admin AI assistant.
• Unit tests cover URL selection, Bearer auth, native request preservation, response-handler selection, and unsupported endpoints/models.
• If a dedicated enum is introduced, frontend option/icon/i18n/model-fetch support and backend factory mapping land in the same PR so no half-registered channel is possible.

Verification performed in this review

• Confirmed upstream #7525 is open at f773df78 and adds native Chat/Messages/Responses routing plus frontend/provider metadata.
• Confirmed LMM main@1b3eb382 has no StepFun channel/adaptor.
• Confirmed LMM Advanced Custom already contains native OpenAI/Claude/Responses routing, Bearer auth, native response dispatch, and model-list management support.
• Confirmed frontend MODEL_FETCHABLE_TYPES already includes Advanced Custom (58).

No code PR is opened in this pass because the same protocols are already representable in LMM and the upstream provider-specific implementation has not merged yet.