Redis-Synchronized Time: Infrastructure & TimeTravel Helper

[bolshakov]

Creates infrastructure for Redis-synchronized time across distributed Stoplight instances, eliminating clock skew. Implements:

• now() Lua function that reads from redis.call("TIME") for server-authoritative timestamps
• Script inclusion system (@include directives) supporting multiple lookup paths
• Stoplight::TimeTravel helper for deterministic test time control with Redis stack awareness

Time-dependent logic (recovery windows, metrics snapshots, state transitions) requires consistent time across distributed instances. This phase creates the foundation.

Part of: 3-phase refactoring (Phase 1/3) - See GitHub stack below.

• Phase 1: Infrastructure (this PR)
• Phase 2: Test migration (Migration: Use TimeTravel in Unit Tests #918) - no production code changes, tests still pass
• Phase 3: Production code updates (Production Code: Use Redis Time in State & Metrics #920) - no tests changes

Considered alternatives:

• using FUNCTION LOAD/PCALL - convenient, but essentially requires a migration to be executed before the code
• injecting time in tests through an script argument and using "TIME" Redis function in production - two completely different mechanism could be error-prone, sometimes we have varargs and this complicates injection.

[github-actions]

Review price tag

🟢 172 effective lines — about 21–52 min of focused review (based on 200–500 lines/hour). This is within the range where reviewers find the most issues per line, and small changes usually receive feedback the fastest.

Why these numbers?

These minutes are what careful defect-finding costs at 200–500 lines/hour — the rate review studies report, not how long a skim takes. "Effective lines" already exclude generated files and lockfiles. Treat the rates and the 200/400 thresholds as guardrails, not laws.