Flaky tests: the cache's L1 TTL tests give an entry 100 ms to survive the next call #471

What

Two tests in crates/cache/tests/l1_unit.rs insert an entry that lives 100 ms and assert, on the next call, that it is still cached:

• a_factory_chosen_lifetime_shortens_the_ttl: the factory gives the entry a 100 ms lifetime (TTL 500 ms), and the second load must return the cached value ("still live").
• ttl_expiry_forces_rerun: TTL 100 ms, and the second run must return the cached value and leave the factory count at 1.

The whole slack is 100 ms between two calls. On a CI runner busy with the parallel test binaries, more than that passes, the entry has expired, and the factory runs again. That is how the merge queue's run of #468 failed (run 776), where #468 only changes a shell script:

a_factory_chosen_lifetime_shortens_the_ttl ... FAILED
assertion `left == right` failed: still live  (left: 2, right: 1)   l1_unit.rs:524

Proposal

Widen the windows as #348 did for #347, without changing what the tests check. Only the "still cached" assertions need slack; a check that an entry has expired only gets safer when the runner is slow.

• a_factory_chosen_lifetime_shortens_the_ttl: TTL 3 s, a factory lifetime of 1 s for the first two loads (1 s of slack for "still live"). Sleep 1.5 s, then the 60 s load must run the factory again ("expired at 1 s"). After another 1 s it is still cached (2 s of slack for "capped at the TTL"). After another 2.5 s it must have expired at the 3 s TTL, not lived 60 s.
• ttl_expiry_forces_rerun: TTL 1 s, and 1.5 s of sleep before the expired call.

The tests then take about 5 s instead of under 1 s.

Pausing tokio's clock instead does not help on its own. The L1 checks deadlines with tokio::time::Instant, but moka's Expiry evicts on the real clock, so a slow runner could still lose the entry early. The tests also run on the multi-threaded runtime, which start_paused does not support.

Done when

• Both tests keep their assertions and no longer fail under load.