fix(event-display): keep a cut's default range over clone and save/load

[Shivansh1205]

Fixes #1036

Problem

A Cut records the bounds it was constructed with as the values reset() restores. clone() and fromJSON() both rebuild a Cut through that constructor using its current bounds, so any narrowing the user applied silently becomes the new default.

fromJSON sits on the state-restore path — StateManager.restoreCutsFromJSON rebuilds every cut that way and hands the result to the menu, which is exactly what the Reset cuts button operates on:

1. Narrow pT from 0–100 to 40–60, save the state, reload, load it back.
2. The cut correctly reads 40–60.
3. Press Reset cuts → it stays at 40–60. The configured range is gone and cannot be recovered without reloading the event.

Widening back out after narrowing in is the point of that button. Because the number shown is the one the user saved, it reads as the button being broken rather than the range having been lost.

Fix

CutJSON had nowhere to carry the defaults, so:

• Added an optional defaults block (minValue, maxValue, minCutActive, maxCutActive) to CutJSON, populated by toJSON().
• fromJSON() constructs from those defaults, then applies the saved active values on top — so the restored cut reads what the user saved but resets to the collection's real range.
• clone() does the same, building from the source's defaults rather than its current values.

Backward compatibility

defaults is optional and falls back to the active values:

Number(defaults?.minValue ?? json.minValue)

State files written before this change load exactly as they do today — no migration, no error. There is a test pinning that.

On clone()

clone() is called once per collection at load time from cuts still at their configured values (phoenix-loader.ts#L253), so it does not misbehave today. I fixed it anyway because it is the same defect and would bite the first time a cut is cloned after adjustment — but flagging it so reviewers know only the fromJSON half is a live user-facing bug.

Tests

Added to cut.model.test.ts:

• resets a clone to the original defaults, not the narrowed values — fails before
• keeps the clone resettable even when cloned before any change — fails before
• restores config defaults after a save/load round trip — fails before (the headline bug: reset() gives 40 where 0 is expected)
• falls back to the active values for a state file without defaults — pins backward compatibility
• round trips the active cut flags without changing their defaults

I also updated one existing assertion: toJSON had an exact-shape toEqual that now needs the defaults key. Worth noting that the neighbouring test asserting no private defaultMinValue / defaultMaxValue keys leak into the JSON still passes unchanged, since the defaults are nested under their own key rather than flattened onto the object.

Verification

• phoenix-event-display: 44 suites / 399 tests passed, 0 failures.
• phoenix-ng: 62 suites / 221 tests passed, 0 failures.
• eslint clean on both changed files.
• tsc --noEmit reports one error in src/tests/helpers/webgl-mock.ts (three.module has no default export). It is pre-existing — identical on a clean tree — and unrelated to this change.

[github-actions]

🚀 Preview deployed: http://phoenix-pr-1037.surge.sh

Built from 19ad5cd.