perf(webui): skip replay repair for sidecars already proven clean (3.8x on concurrent loads)

[ruizanthony]

Problem

Replay repair runs on every session LOAD, not just on save:

• Session.load() — api/models.py
• _load_session_from_path() — api/models.py

It re-serializes every assistant message to canonical JSON and SHA-256s it
(_canonical_message_digest), for the session and for every compaction
ancestor walked by the lineage. A chat with 4 ancestors pays it five times per
tab refresh.

It is the dominant cost of a cold load

Measured on a live deployment, per load:

Step	Time	Share
JSON read	171 ms	26%
Replay repair	485 ms	74%

A py-spy profile taken under 6 concurrent loads put _canonical_message_digest
as the #1 self-time frame. The work runs under the GIL, so it does not
overlap between tabs:

	Time
1 load alone	0.55 s
slowest of 6 concurrent	10.83 s
serialization factor	19.6x

And it is almost always for nothing

Sampling the 60 most recently written sidecars on that deployment:

Outcome	Count
repair changed nothing	60 / 60 (100%)
repair changed something	0

That is 11.8 s of CPU spent to produce no change at all. A file only needs
repairing once; a clean file stays clean until it is rewritten.

Fix

Memoize the negative verdict only, keyed by the sha256 of the exact file
bytes — the same digest the primary load path already computes for revision
tracking, so the key is free there and ~10 ms on a 5 MB sidecar in the secondary
path (versus the ~485 ms of repair it skips).

A hit means "these exact bytes were already proven to need no repair". Any
write changes the digest and therefore misses the cache.

Results

Measured on 6 real sidecars, same machine, warm, _load_session_from_path:

Scenario	Before	After	Gain
Single load (median)	136 ms	46 ms	2.9x
Single load (6 sessions total)	875 ms	302 ms	2.9x
6 concurrent loads (wall)	1054 ms	279 ms	3.8x
6 concurrent loads (slowest)	1053 ms	277 ms	3.8x

The concurrent gain is larger than the single-load gain because the removed work
was serialized under the GIL: it was multiplying across tabs.

Why this is safe

Skipping repair is equivalent to running it. The collapse helpers
(_collapse_adjacent_duplicate_partials, _collapse_duplicate_incomplete_message_ids,
_collapse_adjacent_exact_assistant_replays,
_collapse_duplicate_durable_empty_assistant_replays) never mutate their input:
they build new lists and return (result, changed), returning the input
untouched when changed is False. A test pins that property, so a future
helper that starts mutating in place fails the suite rather than silently
serving unrepaired sessions.

A positive verdict is deliberately never cached. A file that needs repair
gets rewritten, so caching "needs repair" would key on bytes that no longer
exist. Only "clean" is remembered — the conservative direction: a stale miss
costs CPU, never correctness.

Bounded and fail-safe. 512 entries, LRU eviction, and a missing/None
digest forces the full pipeline.

Tests

tests/test_replay_repair_clean_cache.py — 8 tests, all passing:

• a cache hit returns data identical to the full pipeline;
• a session needing repair is repaired every time and never cached;
• distinct digests never share verdicts;
• a missing digest forces the full pipeline;
• the collapse helpers do not mutate their input (the safety hypothesis);
• the cache stays bounded;
• end-to-end through the real loader: a dirty sidecar is repaired, a clean one
  memoized;
• a rewritten file misses the cache and is re-examined.

Existing suites exercising the modified path also pass:
test_merge_backfill_perf_optimization.py, test_offline_replay_compactor.py
(65 passed together with the new file).

On the broader session/compaction/lineage/sidecar selection (30 files), failures
are identical before and after (13 failed / 350 passed in both runs,
verified by diffing sorted FAILED lists) — they are pre-existing on this
checkout and unrelated to this change.

---

Note on the base branch. The repair pipeline this optimizes
(_repair_session_message_projections) is introduced by #7032, so this branch
is stacked on it rather than on master. Review #7032 first; the diff here is
limited to api/models.py (+89/-4) and the new test file.