[Partner Nodes] feat(ByteDance): declare Seedance 2.5 omni task type (video extension)

[purzbeats]

Warning

Draft, not ready to merge. This was written with Claude Code and needs a real
developer to review it properly before it goes anywhere near master. It is opened
as a starting point for @bigcat88, not as finished work. The design decisions below
are proposals, and at least one of them (the widget rename) has a known migration
cost that someone should weigh in on.

What this does

Seedance 2.5 folds three jobs into one omni endpoint: reference-to-video, video editing,
and video extension. We never sent omni_reference_task_type, so every job ran as auto
and the model inferred the job from the prompt.

Extension was reachable that way but not usable. ratio defaults to 16:9, an extend
requires adaptive, and we only coerced to adaptive for edits. So the default extend run
violated the constraint and failed asynchronously, after the reference upload and the
queue wait.

This replaces the video_editing boolean with a task_type combo mapped onto
omni_reference_task_type, and drives the ratio and duration coercion from it:

task_type	ratio	duration	field sent
absent (text-to-video, first/last-frame)	widget	widget	omitted
auto	widget	widget	omitted
reference	widget	widget	reference
edit	adaptive	-1	edit
extend	adaptive	widget	extend

That last row is the point. An edit inherits the source clip's aspect ratio and length;
an extension inherits the aspect ratio but keeps the requested duration. Per the vendor
docs that duration behaviour is the only constraint separating the two subtasks.

Also in here:

• Reject edit / extend with no reference video before the virtual-library upload
  runs, instead of paying for the upload and a round trip to find out.
• Tailor the TaskTypeConstraint error to the selected task type. The old text always
  told the user to enable video_editing, which for an extend is the opposite of the fix,
  since it pins duration to -1 and discards the length they asked for.
• Handle TaskTypeMismatch, which was previously unhandled and surfaced raw.
• Offer mov output, the provider's recommendation for edit and extend.
• Rename the price badge's widget dependency and its JSONata expression together.
  Missing either one leaves the badge silently stale, with no error and no test.

Scope notes

omni_reference_task_type is a 2.5-only field. Seedance 2.0 has no task_type widget,
falls through to auto, and the field is omitted from its requests entirely.

The text-to-video and first/last-frame nodes share _seedance2_build_request and have no
task_type widget, so the lookup defaults safely and their payloads are unchanged.

Cloud needs no change. The BytePlus proxy buffers the request body, decodes a copy
into the typed struct for billing params only, and forwards the raw bytes. The one body
rewrite is the bitrate_mode injection via map[string]any, which carries an in-code
comment that unmodeled fields survive. There is no OpenAPI request validator on the route,
so the new field passes through untouched. Adding it to openapi.yml in the cloud repo is
worth doing for accuracy but is documentation only, and does not block this.

Billing is unaffected: an extension always carries video input, so it already lands on the
video-input rate in both the badge estimate and the post-run extractor.

Verification

Verified end to end locally against the live API by @purzbeats: extension generates
correctly with the ratio widget left on its 16:9 default, which is the case that fails
on master today.

Automated coverage in tests-unit/comfy_api_nodes_test/bytedance_seedance2_test.py
(8 tests) pins the coercion matrix above, that extend preserves a non-default duration,
that 2.0 omits the field, and that both price-badge references moved together.

Also confirmed manually: all 14 ByteDance nodes still load; the widget appears only on the
2.5 reference node; no video_editing reference remains in tracked files.

Known gaps, deliberately left out

Flagging these rather than quietly expanding the diff.

1. The widget rename drops the setting from saved workflows. Graphs using the old
   video_editing boolean come back with task_type at auto, which is the old default
   behaviour, so nothing breaks. But an intentional edit needs re-selecting. Keeping the
   boolean alongside the combo would avoid this at the cost of two ways to say one thing.
   This is the decision most worth a second opinion.
2. duration: -1 is still unreachable outside an edit, because the slider's minimum is
   4. The vendor docs recommend ratio: adaptive + duration: -1 together as the
   configuration that avoids constraint errors on auto, so this gap costs us twice.
3. The pre-upload guard uses the existing 1.8s minimum. The docs require a 4 to 30
   second source clip for edit, so a 3 second clip passes locally and fails at the API.
4. The prompt keyword requirement is not surfaced in the UI. The docs require the
   prompt to contain an intent keyword (continue / extend forward / extend backward
   for extension; add / remove / replace / change for editing), otherwise the model
   classifies the job differently and returns TaskTypeMismatch even when task_type is
   set correctly. Worth putting in the tooltip.
5. return_last_frame is not implemented. Separate feature with its own output socket,
   complementary to extension: extend continues coherently within the 30 second context
   ceiling, last-frame chaining runs past it but loses coherence at each seam. Already in
   the cloud schema, so it would need no cloud work either.

Suggested test plan for review

• Extend forward: one clip, duration 10, ratio widget left on 16:9. Request must go out
  as adaptive and succeed.
• Extend backward: same setup, prompt phrased as "continue the 5 seconds before @video 1".
  Direction is prompt-only, there is no parameter for it.
• Extend with nothing connected to reference_video: must fail immediately, before upload.
• Edit regression: old video_editing behaviour must be identical under task_type: edit.
• Sibling regression: text-to-video and first/last-frame payloads must be unchanged.
• Price badge: change task_type and confirm it still recalculates.

Docs: Create a video generation task
and Must-read before use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01H8RGpZs478f6b3ps64zgba

API Node PR Checklist

Scope

• Is API Node Change

Pricing & Billing

• Need pricing update
• No pricing update

If Need pricing update:

• Metronome rate cards updated
• Auto‑billing tests updated and passing

QA

• QA done
• QA not required

Comms

• Informed Kosinkadink

[github-actions]

🎉 Thank you for your contribution, we really appreciate it! 🎉

Like many open source projects, we require contributors to sign our Contributor License Agreement (CLA). A CLA makes the ownership of contributions explicit, so contributors and the project share a clear understanding of how the code can be used. By signing, you:

• Confirm that you own your contribution.
• Keep the right to reuse your own code.
• Grant us a copyright license to include and share it within our projects.

CLAs are standard practice across major open source projects including those under the Apache Software Foundation and the Linux Foundation. Ours is based on the Apache Software Foundation's CLA. Most importantly, it would enable us to relicense the project under a more permissive license in the future, giving the project and its community greater flexibility.

✍ To sign, please post a new comment on this PR with exactly the following text: ✍

---

I have read and agree to the Contributor License Agreement

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[purzbeats]

Closing in favour of #15579, which carries this change forward from @bigcat88.

That PR is based on this one and is the version to review and merge. Everything here is superseded, including the follow-ups noted above (return_last_frame, reaching duration: -1 outside an edit, the 4 second source minimum on edits, and surfacing the prompt intent keywords in the tooltip), which are worth tracking against #15579 instead.

Thanks @bigcat88 for picking it up.