fix: make rate limiter checks independent of window size (#125)

[jonbaldie]

Fixes #125

Diagnosis

RateLimiter.isAllowed() (src/rate_limiter.ts) ran timestamps.filter(ts => ts > cutoff) on every call — an O(window) scan and allocation per request, paid before authentication (rate limiting wraps auth) and even for requests that end up denied. Filling one caller's window and issuing denied requests therefore scaled linearly with RATE_LIMIT_REQUESTS, collapsing quadratically under sustained load.

Confirmed with a live benchmark (docs/exploratory-testing/2026-09-21-queue/perf_repro.ts), matching the triage timings on the issue:

window	before	after
1,000	0.018 ms/req	0.007 ms/req
10,000	0.10–0.13 ms/req	0.002–0.006 ms/req
growth ratio	3.8–9.5× (linear)	0.4–1.4× (flat)

Fix

Timestamps are appended in non-decreasing order, so stale entries always form a prefix of each caller's array. Instead of filtering on every call:

• Fast path (O(1)): if the newest timestamp is fresh, nothing is stale.
• Otherwise binary search the first fresh timestamp — O(log n) — and make the allow/deny decision from freshCount = length - firstFresh, without copying the window.
• Drop the stale prefix only once it dominates the array (firstFresh * 2 >= length), so the copy stays amortized O(1) per recorded request.
• All-stale entries are still deleted (then re-added on the next allowed request); cleanupStaleEntries(), maxTrackedIPs eviction (last element = max timestamp still holds), the sliding-window boundary (ts > cutoff), client identity, and the 429 contract are unchanged.

Tests

• High-window behavior: 10,000-entry fill denies at the limit; a fully stale 10,000-entry entry recovers with a single fresh timestamp; a stale prefix does not count toward the limit and is trimmed exactly when it is half the array (>=, not >).
• Perf canary: 2,000 denied requests at a full 10,000-entry window must complete in < 80ms (pre-fix ~210ms; post-fix ~1-3ms timed section) — fails on the old implementation, passes on the new one.
• All 34 existing rate-limiter tests pass unchanged (eviction ordering, cleanup sweeps, boundary conditions).

Note: persist.ts mutation coverage

The second commit is CI infrastructure repair, not part of the rate-limit fix: the atomic-snapshot rewrite in #122 left src/persist.ts at 78–79% on the Stryker mutation gate (80% per-file threshold), which has kept main's Mutation testing (Stryker) job red since Sep 20. Any PR touching tests runs the full mutation suite, so this PR cannot go green without restoring those kills. The new tests kill the survivors through the public FileStore interface only: full truncation of stale temp content, rethrowing when the temp path is unusable, temp cleanup on failed rename, and multi-byte reassembly across 4096-byte read boundaries.