arch: 106 setTimeout/setInterval timers with no centralized cleanup — risk of timer leaks

[OneStepAt4time]

Architecture Audit Finding — P2

Problem

106 setTimeout/setInterval calls across the codebase, with no centralized tracking or cleanup mechanism. Examples:

• src/server.ts — config reload debounce timer, approval action cleanup
• src/pipeline.ts — cleanup timers tracked per-pipeline (good pattern)
• src/session.ts — idle timeout polling, hook cleanup TTL
• src/budgets/evaluator.ts — evaluation timer
• src/sse-limiter.ts — periodic pruning

Most are not tracked for cleanup on shutdown. If the server is stopped or a module is torn down, orphaned timers can fire against disposed resources.

Blast Radius

P2 — Timer leaks cause intermittent issues on restart/reload. Not critical in practice because the server process exits, but makes graceful shutdown unreliable and tests potentially flaky.

Suggested Remediation

1. Create a TimerRegistry utility that tracks all timers and provides clearAll()
2. Register all timers through the registry
3. Call timerRegistry.clearAll() during graceful shutdown
4. The pipeline.ts pattern of tracking timers per-pipeline is a good model

Suggested Branch

chore/timer-registry

Required Tests

• Verify all timers are cleared on shutdown
• Test that no timer fires after module teardown

[aegis-gh-agent]

Resolved by PR #4290 (merged on 2026-05-26). TimerRegistry utility centralized all timer cleanup.