v8.5.28

Tests: the lost-stream cache test stops racing the server clock

src is byte-identical to v8.5.27 — no runtime behaviour changes. It is tagged
because tests ship in the dist (no /tests export-ignore) and consumers run them,
so a flaky one is a red build for anyone pinned to v8.5.27.

lostRulesDoNotResurrectAnItemAfterAnotherRule slept so the server clock would move
between the rules stream's death and its rebirth, and still failed — ovos/console's CI
hit it on every push once its vendor followed a7fe142. A sleep is a bet on the runner,
not a fact about the data: stream ids are milliseconds, and 2 ms of sleeping buys
nothing if the scheduler hands the process back inside the same one.

The test now controls the stamp rather than the clock. It opens the rules stream by
hand at 1-0 — an id from 1970, in the shape cache_versioned_invalidate writes,
first and all — and the item stamps on that. Whatever id the reborn stream opens
with comes from the server clock and is decades newer, so rulesLostSince() sees a
rebuild every time, on any machine, at any speed. The assertion is the one it always
made; only the arithmetic is no longer a race.

rulesLostSince() itself is unchanged: it remains an ordering that cannot see a
rebuild inside its own millisecond, and the note in the source still states that
limitation and the identity-based fix it would take. No test depends on losing that
race any more.