Review SLA and escalation #37

Problem

ActionRisk:ReviewWaitingThreshold marks an action at risk after eight hours and then does nothing. Risk with no consequence is decoration.

The business problem is not that developers see too many notifications. It is that pull requests sit waiting. An SLA turns a personal preference into a team commitment, which is what makes this sellable to a team rather than an individual.

Scope

• Per-repository and per-team review SLA targets, for example "reviews answered within 8 working hours"
• Working-hours and timezone awareness, so a weekend does not burn an SLA
• On breach: escalate to a backup reviewer, mark the action and the team queue, and optionally notify
• SLA attainment visible on the team queue

Acceptance criteria

• SLA targets configurable per repository and per team, with an installation default
• Working hours, timezone and holidays are respected in elapsed-time calculations
• Breach escalation is configurable: notify, reassign to a backup reviewer, or both
• Breaches are recorded so attainment can be reported over time
• SLA state is filterable and usable in Rules
• Reporting is aggregate by team or repository, never a per-person league table

Notes

Deliberately measures the system, not the individual. See docs/productidea.md section 12.