fix(core): stable zIndex child sort for Chrome < 70

[chiefcll]

What changed

• CoreNode.sortChildren() now uses a stable, allocation-free insertion sort (sortByZIndexStable in src/core/lib/collectionUtils.ts) instead of Array.prototype.sort.
• Removed the unused bucketSortByZIndex and the now-unneeded hoisted compareZIndex comparator.
• Added unit tests for sortByZIndexStable (src/core/lib/collectionUtils.test.ts).

Why

Array.prototype.sort is not stable on Chrome < 70 — V8 used an unstable quicksort for arrays longer than 10 elements. On our Chrome 38 embedded targets, equal-zIndex siblings (the common case: most children have zIndex 0) could silently reshuffle paint order whenever a parent with more than 10 children re-sorted. Insertion sort is stable, zero-allocation (no comparator closure, no buckets), and O(n) on the nearly-sorted children arrays this path actually sees — a re-sort typically follows a single zIndex change.

The deleted bucketSortByZIndex was dead code (no imports) with real defects: it indexed buckets by zIndex - min, so a legal huge zIndex (the setter only clamps beyond MAX_SAFE_INTEGER) allocated an enormous sparse array, and below-min or fractional values landed in negative/fractional indices stored as object properties that buckets.length = 0 never cleaned up.

Notes for reviewers

• Stability for equal keys means scenes that never set zIndex keep exactly their insertion order — this is a behavior fix on old Chrome and a no-op on Chrome 70+ (where the native sort is already stable).
• Tests include a >10-element stability case specifically covering the V8 quicksort threshold.
• Unit tests were not run to completion locally before pushing (per request); CI should confirm.

🤖 Generated with Claude Code