Sort lineage entries by timestamp then id for deterministic list output

[spapin]

Problem

SegmentLineage.toJsonObject() sorted entries by millisecond timestamp only, over a HashMap. Entries sharing a millisecond fell back to arbitrary UUID-hash iteration order, so the list API output was non-deterministic. testListSegmentLineage asserts two back-to-back startReplaceSegments entries appear in a fixed order; on a fast machine the two share a millisecond ~57% of the time, and the assertion failed ~29% of runs (measured over 1000 runs).

Fix

Add the entry id as a sort tiebreaker: entries are ordered by (timestamp, then id). This makes the list output deterministic for a given set of entries. Entries remain identified by UUID. The code generally doesn't make any use of the ordering, but segmentLineage prints a summary where segments at the same millisecond may appear out of order.

The test derives the expected order with the same (timestamp, id) sort and asserts the response lists the two entries in that order — deterministic regardless of whether the timestamps tie.

[spapin]

The biggest benefit for this PR is to fix the flaky test on fast machines. This isn't an impactful bug otherwise.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.82%. Comparing base (bec3dcc) to head (0dd64ac).

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #18859      +/-   ##
============================================
+ Coverage     57.00%   64.82%   +7.81%     
- Complexity        7     1322    +1315     
============================================
  Files          2607     3393     +786     
  Lines        152679   211308   +58629     
  Branches      24816    33226    +8410     
============================================
+ Hits          87041   136971   +49930     
- Misses        58227    63277    +5050     
- Partials       7411    11060    +3649     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-21	64.82% <100.00%> (+7.81%)	⬆️
temurin	64.82% <100.00%> (+7.81%)	⬆️
unittests	64.81% <100.00%> (+7.81%)	⬆️
unittests1	57.00% <0.00%> (-0.01%)	⬇️
unittests2	37.19% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Vamsi-klu]

Read through the fix; it looks correct and well-scoped. Map.Entry.<String, LineageEntry>comparingByValue(comparingLong(getTimestamp)).thenComparing(comparingByKey()) is a total order (timestamp primary, unique map-key id as tiebreaker), so forEachOrdered into a LinkedHashMap makes toJsonObject() output deterministic. The explicit <String, LineageEntry> type witness is genuinely needed here, otherwise the key type is unconstrained and thenComparing(comparingByKey()) won't resolve.

Nice that the test isn't tautological: it re-reads the persisted SegmentLineage and derives the expected order with the same (timestamp, then id) comparator, so the assertion is driven by the id tiebreaker rather than a hardcoded order. Worth noting the regression guard is probabilistic, not deterministic: it only catches a revert to timestamp-only sorting on runs where the two entries tie on the same millisecond and HashMap iteration order disagrees with id order. When the timestamps differ, both old and new sorts agree and the test passes either way. That's fine given the whole point is flaky sub-millisecond ties, just calling it out so no one assumes it hard-fails on any revert. Clean, low-risk fix. LGTM.