fix: lit-light transfer, torch sprite dialogs and Momentum first term (#134, #137, #138)

[DimitroffVodka]

What

Four fixes, one commit each:

Commit	Fix
57d8cdbc	Momentum first term (#134). Momentum finds the damage formula's first dice term with the system's own pattern, so terms like 1d(6+2) no longer get exploded twice.
1e75bbce	Sprite config windows (#137). The Equipped Sprite and Torch Sprite windows scroll inside a resizable window that fits the screen, and Save/Cancel always stay visible.
d251a8c8	Torch Sprite flame. Moving or rescaling the torch prop in the dialog now carries the flame with it.
b95908cd	Lit light transfer (#138). Transfer to Player moves a lit light's token light and torch sprite to the receiver.

How

• Momentum not applying to bonus dice #134: SDX's DICE_TERM also matched terms the system's pattern skips (1dF, 1d(6+2)), so the two could disagree about which term comes first. SYSTEM_DICE_TERM copies the SD 4.0.6 pattern, and the dice terms on both sides of the system's first term get exploded. docs/wiki/Combat-and-Damage.md no longer says the Momentum toggle doesn't fix the system bug.
• Sprite and Weapon Animation config menu too big. #137: Foundry caps .application height and hides overflow, so the tail of a tall form was cut off with no scrollbar. The fix is a flex scroll area with the footer outside it. The Weapon config window also calls setPosition() again when it grows, because Foundry only keeps a window on screen when its position is set, not when its content grows.
• Torch flame: a change to the dialog only. It remembers where the flame sits on the prop and rebuilds the flame position and size after each prop edit. The saved torchSprite values keep their meaning, so there's no migration and the code that draws the sprite in play is unchanged.
• Light Sources Transfer to Player #138: nativeTransferItems copied the lit item and deleted the original but never moved the light. It now hands the light over the way the system's sheet drop does:
  • it puts out the receiver's own light, creates the copy, then calls turnLightOff on the giver and turnLightOn on the receiver
  • the existing createItem/updateToken hooks move the sprite
  • a lit item never merges into an existing stack, and a split of a lit stack arrives unlit

Test plan

• New tests: weapon-momentum.test.mjs (first-term boundary), torch-sprite-flame-follow.test.mjs, and transfer-lit-light.test.mjs. On the code before the fix, three of the transfer file's four cases fail.
• npm test: 1644 pass, 0 fail
• npm run verify: verify: OK
• Each fix was checked live on V14 with SD 4.0.6:
  • Momentum not applying to bonus dice #134: 1d4 + 1d6 became 1d4x + 1d6x, and 1d(6+2) + 1d6 became 1d(6+2)x + 1d6x.
  • Sprite and Weapon Animation config menu too big. #137: Save stayed on screen with the image browser open and the window capped at 600px.
  • Torch flame: moving and rescaling the prop carried the flame. Cancel restored the saved config.
  • Light Sources Transfer to Player #138: a player gave a lit Oil Flask to a character they don't own, which goes through the GM, in both directions. Token lights, sprites and the light tracker all moved, checked from the GM and both players' views.

Known gaps, not fixed here

• Light Sources Transfer to Player #138:
  • The party sheet's Transfer to member, and the trade window when Item Piles is active, still move a lit item without its light.
  • When the GM relays the transfer, the GM's current scene decides which token gets the light. The system's own torch pickup has the same limit.
• Torch flame: saved configs whose prop was moved before this fix keep their out-of-place flame until the flame sliders are touched once or Reset is used.
• Momentum not applying to bonus dice #134: SYSTEM_DICE_TERM is a hand copy of the system's regex. A future system change to that pattern could make them disagree again.

Fixes #138. Refs #134, #137.

🤖 Generated with Claude Code

[DimitroffVodka]

[P2] Preserve the flame anchor when carried values exceed bounds (scripts/animation/TorchSpriteConfig.mjs:149-151)

Fixed in 7729c38.

The flame sliders can't be widened to fit a carried value, because <range-picker> reads its min/max once, in its constructor. So a prop edit now stops where the flame reaches its limit:

• fitProp finds how far the edited prop field (X, Y or scale) can go before any carried flame value (X, Y or size) leaves its slider range, and stops the prop there.
• It rounds that stop toward the allowed side. The picker rounds to its nearest step, so it could otherwise land just past the limit.

With the default torch, prop X now stops at 0.85, and the flame lands at exactly 1 on the same spot of the prop.

Tests: 3 new cases in torch-sprite-flame-follow.test.mjs: the upper limit, the lower limit, and a limit that falls between steps (1.714, rounded down to 1.7). npm test 1647/1647, verify: OK, CI green.

Live check in the real dialog, on an unlit Torch:

• Dragging prop X to 1 stopped at -0.1, with the flame at exactly 1 and still on the same spot of the prop.
• Dragging scale to 3 stayed at 1.5, because the flame was already at its right-hand limit.
• Cancel left the saved settings unchanged.

Behaviour change: when the flame is near an edge, a prop slider now stops before its end. Moving the flame first frees it.