Resource control: residual backend timing constants configurable

[mark-e-deyoung]

Summary

Make backend hardcoded runtime timing constants configurable to better control resource behavior across environments.

Problem

Several endpoint and worker paths still use inline fixed values (timeouts/sleeps), which are arbitrary and not centrally tunable for different hosts/load profiles.

Scope

• Inventory hardcoded timing values in API/router/monitor paths.
• Add validated env/config knobs for selected high-impact constants.
• Keep safe defaults equivalent to current behavior.
• Add tests that verify overrides are applied.

Candidate areas

• command invocation endpoint timeouts
• probe/retry sleeps in input/automation routes
• stream and polling sleep intervals where server-side tuning is appropriate

Acceptance criteria

• No high-impact arbitrary timing constants remain hardcoded without configuration path.
• Defaults preserve current behavior.
• Regression tests validate override semantics.

[mark-e-deyoung]

Release triage update (2026-02-25): Partially implemented.

Recently delivered:

• configurable shutdown guard TTL
• configurable resource monitor/session cleanup intervals
• configurable log-follow acquire timeout

Residual scope kept open in this issue:

• remaining backend timing constants still hardcoded in route/probe/retry paths
• tests verifying override semantics for those remaining paths

Recommendation:

• keep open with narrowed scope; prioritize only if a dependent project is blocked by specific timing behavior.