fix(resume-library): same-millisecond savedAt ties list resumes oldest-first

[s-annam]

src/lib/resume-library.test.ts > lists saved resumes newest-first failed a single run while several agents ran concurrently during the #744/#745/#746 batch, then passed 5/5 in isolation. It is untouched by that branch and pre-existing.

Root cause

src/lib/resume-library.ts:156 sorts with:

b.savedAt - a.savedAt

savedAt is a Date.now() millisecond. Two saves that land in the same millisecond make the comparator return 0, and Array.prototype.sort is required to be stable — so the tie preserves insertion order, which is oldest-first. That is exactly the inversion the test observed.

The test saves back-to-back with no delay, so whether it passes depends on whether the machine crossed a millisecond boundary between the two writes. Under load it does not.

Why it matters beyond the test

The same tie affects the product: a user who saves two resumes in quick succession gets them listed oldest-first in the library. Rare, but not test-only.

Fix options

1. Tie-break on a monotonic secondary key in the comparator (insertion index, or id if it is monotonic) so equal savedAt still resolves newest-first.
2. Make the test deterministic — fake timers, or distinct explicit savedAt values — which fixes the flake but leaves the product behaviour.

(1) addresses both; (2) alone would close the flake while leaving the ordering bug.

Repro

npx vitest run src/lib/resume-library.test.ts

Not reliably reproducible on an idle machine — run it under concurrent load, or temporarily stub Date.now() to a constant to make the tie deterministic.

[s-annam]

Already fixed on main, and this issue outlived its own fix.

src/lib/resume-library.ts:212 reads:

.sort((a, b) => b.savedAt - a.savedAt || a.id.localeCompare(b.id));

That is option (1) from the body — a deterministic secondary key, so equal savedAt no longer falls back to insertion order. It landed under #907 ("Flaky sort: listLibrary() ties on same-millisecond savedAt, misordering under contention"), closed completed 2026-08-27, which was filed and fixed independently while this issue stayed open.

Closing as a duplicate of #907 rather than leaving a fixed defect on the tracker.

Caught while curating #901 — this had just been labelled good first issue, and a newcomer opening it would have found the fix already in place. The label is removed.