fix(traces): slide the trace list and drop what storage evicted

[htcom-code]

Why

The trace list only ever grew: every batch merged in and nothing came out except a clear. That causes two problems.

1. Cost. A long session re-sorts the whole list on every batch. At 24 h × 10 req/s that is about 860k rows.
2. Honesty. Eviction deleted rows from IndexedDB but not from the list. Measured on main with a retention limit of 8, after ten arrivals:

6/6  7/7  8/8  9/8  10/8 … 15/8   (shown / retained)
rows on screen that are not in storage: 7

At the real limit (50,000) this takes longer to reach, but the list grows without bound, so a long session ends up in the same state.

What

Sliding window. The list holds the newest keep rows: one page to start, plus one page for every "load older". New traffic pushes the oldest rows out of the bottom. Those rows are still in storage, so hasMore turns on and "load older" brings them back. A clear resets the window to one page.

Eviction sync. pruneOldest now reports how far it reached: the last deleted row's (epochMillis, _key), in index order. Rows at or before that position are dropped from the list and from any search result. The screen therefore loses exactly what storage lost, including rows that share the boundary millisecond.

Infinite scroll. Nothing changes while the user is parked at the bottom. A batch leaves the row count and last index the same, so the load does not fire again.

Verification

• 5 new scenarios in trace-window.test.ts: no ghost rows after eviction, ghost rows dropped from search results too, window slides, window grows only by explicit loads, hasMore turns off when storage is exhausted. Against the old store, 4 fail. The fifth guards the end-of-storage case.
• Not checked in a browser. It needs a platform with traffic past the retention limit, and the backend was not running.
• npm run lint: 7 warnings, the same set as main
• npm test: 18 files, 207 tests pass