Duplicate timing events at the same position resolve by token value instead of file order

Context

Found in the BMS spec-compliance audit (finding C-4). De-facto BMS implementations (LR2 / beatoraja) resolve duplicate definitions at the same timeline position with last-written-in-file wins.

Current behavior

When two #xxx03 / #xxx08 (BPM), #xxx09 (STOP), SC, or SP events land on the same measure/position from separate lines, the winner is decided by the token value sort order, not the source order:

• compareEvents (packages/chart/src/index.ts) tie-breaks same-position events by channel → value, and the original file order is lost after sortEvents.
• The tempo integrator (packages/audio-renderer/src/core/triggers.ts, integrateTempoPoint) and the scroll/speed keyframe merge (packages/player/src/core/scroll-distance.ts) then take the last entry of the sorted run.

Expected behavior

The definition written later in the file should win, matching LR2 / beatoraja.

Notes

• Only affects pathological charts that author conflicting duplicate definitions at the exact same position; low priority.
• A fix likely needs a stable source-order index on BeMusicEvent (or preservation-side ordering) so the tie-break can use it — a small IR addition with round-trip implications.

Start by tracing compareEvents and sortEvents in packages/chart/src/index.ts, then follow how integrateTempoPoint in packages/audio-renderer/src/core/triggers.ts and the keyframe merge in packages/player/src/core/scroll-distance.ts consume same-position events. Check how BeMusicEvent ordering survives the pipeline and define done as later file definitions winning consistently for BPM, STOP, SC, and SP duplicates without breaking round trips.