Refactor auth token refresh to use sliding expiration

Summary

• Replaces fixed 1-hour token TTL with sliding expiration that resets on activity, reducing session churn for active users
• Extracts TokenRefreshService from AuthMiddleware into its own injectable class to make the policy independently testable
• Adds a token_refresh_policy feature flag so the new behavior can be enabled per-environment before full rollout

Why this change

The current fixed-TTL approach was logging ~340 forced logouts per day for users in long-running workflows (reported in #1847). The root cause is that AuthMiddleware refreshes the token only on initial validation, not on subsequent requests within the window.

This was deferred during the original auth implementation (see ADR-012) with a note to revisit once session analytics were available. We now have 30 days of data confirming the pattern.

Alternatives considered

Extend fixed TTL to 4 hours — Reduces logouts but doesn't eliminate them for day-long sessions; also widens the blast radius if a token is compromised. Rejected.

Refresh on every request — Correct behavior but adds a Redis write on every authenticated endpoint. Profiled at ~4ms p99 overhead under load test; acceptable, but sliding expiration achieves the same UX improvement with ~60% fewer writes. Rejected in favor of sliding window.

What changed

| File | Change | |---|---| | src/auth/middleware/auth.middleware.ts | Delegates refresh logic to TokenRefreshService; no longer owns TTL policy | | src/auth/services/token-refresh.service.ts | New. Implements sliding expiration with configurable windowSeconds and thresholdSeconds | | src/auth/auth.module.ts | Registers TokenRefreshService as a provider | | config/feature-flags.yaml | Adds token_refresh_policy: fixed \| sliding (default: fixed) | | src/auth/services/token-refresh.service.spec.ts | New. 14 unit tests covering boundary conditions on window/threshold math | | src/auth/middleware/auth.middleware.spec.ts | Updated mocks to inject TokenRefreshService; removed TTL logic tests now covered upstream |

Test plan

• [x] Unit: token-refresh.service.spec.ts — window expiry, threshold not-yet-reached, threshold exactly at boundary, clock-skew tolerance
• [x] Unit: auth.middleware.spec.ts — verifies middleware delegates correctly, does not call Redis directly
• [x] Manual: enabled sliding flag in local dev; confirmed session persists across a 90-minute workflow without re-login
• [ ] Reviewer action needed: integration test against staging Redis once flag is flipped — see rollout note below

Risk areas for reviewers

• token-refresh.service.ts lines 44–67 — The threshold guard (remainingTtl < thresholdSeconds) must be evaluated after fetching current TTL from Redis, not from the in-memory request timestamp. A race condition here could cause double-refresh under high concurrency. Please verify the ordering.
• config/feature-flags.yaml — Default is intentionally fixed to preserve current behavior in production. If this file is cached by the config service at startup, a deploy without restart will not pick up a flag flip. Confirm with platform team before staging test.
• auth.module.ts — TokenRefreshService is registered as request-scoped. If it is accidentally changed to singleton, sliding state will leak across users.

Rollout

⚠️ This change touches production auth paths.

1. Deploy with token_refresh_policy: fixed (default) — no behavior change on deploy
2. Enable sliding in staging; run integration suite and monitor Redis write rate
3. Enable sliding in production via config update (no redeploy required)
4. After 7-day soak, remove fixed branch and flag — tracked in #1902

Related

• Closes #1847
• Refs ADR-012: docs/adr/012-session-management.md
• Follow-up: #1902 (flag removal)