[Partner Nodes] fix(ByteDance): Layer Separation wiring tooltips + exact 2K price

[christian-byrne]

Targets feat/api-nodes/bytedance-layer-separation so it can land inside #15351 without disturbing its approval. Two independent commits — drop the second freely if the rate card says otherwise.

1. The wiring tooltips point at sockets that no longer exist

Five tooltips on ByteDanceSeedreamLayerSeparationNode tell the user to wire into image_0, mask_0, image_1 and mask_1 of Create Layered Image.

ImageCompositor replaced its two io.Autogrow.Inputs with a single io.Image.Input("image") + io.Mask.Input("mask") in commit 9232943a on #15317 ("feat: single batched inputs, transparent default, experimental flag", 2026-08-06T23:06Z) — after this branch's only commit (15:13Z). Those sockets are gone, so the instructions cannot be followed as written. Anyone doing QA from the tooltips stalls on step one.

Rewritten to describe the real path: batch base_image ahead of layers (and base_mask ahead of masks) with Batch Images / Batch Masks, then feed the batches to image / mask. Base-first is what the bboxes list already assumes, so the index alignment is preserved.

2. Two statements that were wrong independently of that change

Both are in the crop_layers tooltip:

• It calls minimal-size "the pairing expected by Create Layered Image". It is the opposite. batch_images (comfy_extras/nodes_post_processing.py:514) resizes every frame to the first frame's size via common_upscale(..., "bilinear", "center"). Cropped layers are not base-sized, so batching them behind the base silently centre-crops and rescales each one, destroying exactly the placement the mode exists to preserve. Full canvas is the mode that survives batching — and it is already the default.
• It says full canvas lets you "recompose directly with ImageCompositeMasked". That node does mask = torch.ones_like(source) when no mask is given (comfy_extras/nodes_mask.py:25-26), i.e. 1 = opaque — the inverse of this node's LoadImage convention. An InvertMask is required first, as the masks tooltip already correctly says.

Tooltip text only; no behaviour change.

3. 2K renders as a price range when its price is known

size has four options: auto, 1K, 1.5K, 2K. The badge returns an exact 0.032 for 1K/1.5K and falls through to a 0.032–0.064 range for everything else — so 2K shows a range even though only auto is genuinely unresolved at graph-build time. Added a 2K branch returning the range's own upper bound.

Evaluated against jsonata 2.x with the frontend's normalisation (normalizeWidgetValue lowercases COMBO values before evaluation, src/composables/node/useNodePricing.ts:229-233):

auto -> range_usd 0.032-0.064
1k   -> usd 0.032
1.5k -> usd 0.032
2k   -> usd 0.064

0.064 is inferred from the existing range's max_usd — please confirm against the Metronome rate card before merging, since the pricing checkbox on #15351 is still unticked. It is a standalone commit precisely so it can be dropped.

Note on a non-issue

The lowercase ["1k", "1.5k"] comparison against uppercase combo options is correct, not a case bug. The frontend lowercases COMBO widget values before JSONata evaluation, and the sibling Seedream badge in the same file uses the same convention ($contains($sp, "1k"), nodes_bytedance.py:917). Flagging it here because it has been raised as a suspected bug more than once.

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

[bigcat88]

Thanks for catching the stale socket references — the Autogrow removal in 9232943a is real, and the current tooltips do point at sockets that no longer exist.
Commit 2 (flat 2K price): the premise doesn't hold — element layers don't come back at 2K resolution. Measured on live 2K runs, element layers arrive as tight crops at e.g. 1501×1506 (2.26 MP), 1491×1492 (2.22 MP), 932×2061 (1.92 MP) — consistently under the 2.61 MP per-image tier boundary; only the 2048×2048 background (4.19 MP) crosses it. The rate card itself expects this: elements are usually cropped regions below the boundary, with the full-size background above it. With per-image tiering, a typical 1-background + 3-element 2K job comes to 0.064 + 3×0.032 = 0.160, while the flat badge suggests 4×0.064 = 0.256 — roughly 60% over. Elements can exceed the boundary ("usually" isn't "always"), which is exactly what the range badge communicates. Per the note in your description, I'd drop this commit and keep range_usd for 2K.

[bigcat88]

Tool-tip changes were taken. Pricing was correct in our PR.

Big thanks for this and for reviews on parent PR. Closing this PR as everything is already incorporated into a single parent PR.