fix(task): make Seedance/Wan capability billing model-specific

[LIghtJUNction]

Upstream source

QuantumNous/new-api commit: QuantumNous/new-api@65d3a21

Upstream stopped sharing one video usage schema across every Seedance/Wan model. The fix now derives billable/accepted dimensions from per-model capabilities, rejects unsupported resolutions before submission, reserves a valid highest tier when the provider chooses the resolution, and only applies audio/reference-video facts to models that actually support them.

Relevant upstream areas:

• plugins/tasks/doubao/plugin.js
• plugins/tasks/alibaba/plugin.js
• plugins/doubao_responses_test.go
• plugins/alibaba_responses_test.go

Examples from the upstream capability table:

• Seedance 1.0 family: 480p/720p/1080p, no reference-video billing dimension.
• Seedance 1.5 Pro: 480p/720p/1080p plus generate_audio.
• Seedance 2.0: 480p/720p/1080p/4k plus reference-video input.
• Seedance 2.0 Fast/Mini: 480p/720p only plus reference-video input.
• Seedance 2.5: 480p/720p/1080p plus reference-video input.
• Wan profiles now expose only each model's supported resolutions; wan2.6-i2v-flash additionally prices audio vs silent output.

LMM source audit

LMM does not yet use the upstream task-plugin usage-schema host, so this is not safely cherry-pickable.

Current native Doubao task code has the same class of capability gap:

• apps/api-go/relay/channel/task/doubao/constants.go advertises Seedance 1.0/1.5/2.0/2.0-fast.
• videoPriceTable only has explicit capability/price rows for 2.0 and 2.0-fast.
• GetVideoInputRatio() deliberately falls back to 1.0 when a combination is missing; the comment specifically cites fast 1080p/4k and relies on the upstream API to reject it.
• EstimateBilling() consumes that result before submit, so request validation and billing capability knowledge are not sourced from one model profile.

Current native Alibaba task code has a similar split:

• apps/api-go/relay/channel/task/ali/adaptor.go::ProcessAliOtherRatios keeps a separate per-model resolution-price map.
• convertToAliRequest() accepts generic 480P/720P/1080P handling/defaults independently from that map.
• The advertised model list is different from upstream's new plugin catalog, so missing/new Wan models must not be added mechanically.

Related but not duplicate: #405 tracks whether LMM should adopt the generic task-plugin host at all. This issue is about correctness of the current native Go task adaptors even if #405 is rejected.

Suggested adaptation

1. Introduce a small native per-model capability descriptor for the Seedance/Wan models LMM actually advertises today. Do not import the JS plugin runtime just for this fix.
2. Use the same descriptor for request validation and billing-dimension selection, so unsupported resolutions/dimensions cannot silently fall back to a base price.
3. Reject explicitly unsupported resolution/model combinations with a 400 before the upstream request.
4. When resolution is omitted and the provider chooses it, reserve conservatively using a supported tier rather than an impossible/default row; settle only from provider-reported facts that belong to that model's profile.
5. Only add audio/reference-video billing dimensions where the model actually supports/prices them.
6. Do not advertise new Seedance/Wan model IDs until their current endpoint/protocol and LMM billing behavior are verified independently.
7. Keep configured model price/ratio, dynamic pricing, group ratio, model price lock and /fast behavior unchanged outside the capability multiplier itself.

Acceptance criteria

• Tests enumerate every Seedance/Wan model currently returned by each native adaptor and prove it selects one explicit capability profile.
• Seedance 2.0-fast rejects 1080p/4k locally instead of silently using the base billing ratio and waiting for Ark to fail.
• Seedance 2.0 still accepts 4k; Seedance 1.x does not gain reference-video billing merely because such metadata is present.
• Any model with audio-specific pricing records audio/silent state; models without that dimension ignore it for billing.
• Alibaba/Doubao request validation and EstimateBilling() agree on supported resolution sets.
• Omitted-resolution reservation is conservative but settlement never invents an unsupported resolution from provider output.
• Existing configured prices and price locks are not rewritten.
• Focused task-adaptor tests plus existing Go CI/release qualification pass.

Do not do

• Do not copy upstream plugin/UI/business code wholesale.
• Do not add unverified model IDs solely because upstream advertises them.
• Do not change LMM's task settlement/refund lifecycle as part of this fix.