ci/woodpecker/pr/ci Pipeline was successful
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.