Closes#1090.
`clamps ttlSeconds to 900` asserted a wall-clock delta against a fixed 100 ms
budget:
expect(expiresMs - before).toBeLessThanOrEqual(900_000 + 100);
That budget covers everything between `Date.now()` and the service computing
`expiresAt`. On a loaded CI agent — this step runs alongside a Postgres service
container and several other workspaces — it came back at 900_106 and failed by
6 ms (#1090, observed on pipeline 2258).
The property under test is CLAMPING: a 9999s request must come back as 900s.
The gap between clamped and unclamped is 9_099_000 ms, so the tolerance only has
to exceed scheduler jitter to stay discriminating:
clamped ~900_000 ms <= 905_000 ✓ < 1_000_000 ✓
unclamped ~9_999_000 ms <= 905_000 ✗ < 1_000_000 ✗
A 5s allowance consumes 0.055% of that margin, and an unclamped implementation
still misses by three orders of magnitude.
Also pins the clamp explicitly with `toBeLessThan(1_000_000)`, so the property
is asserted independently of any timing allowance — widening the jitter budget
later cannot silently weaken it.
NOT DONE: I could not execute vitest here (no node_modules; a full install is
minutes). The discrimination argument above is arithmetic, not an executed
red/green. A reviewer should run the suite, and if it is cheap, confirm that
removing the clamp in the service still fails this test.
Mos