feat(slos): multiwindow burn-rate alerts - #2296

🟢 Confidence 10/10 · safe to merge. Hold semantics ride alerting-core's existing hold tier and the tier/destination pairing is now pinned by scheduler tests; only two info-level copy/flag items remain open.
_{2 notes · tests covered · risk medium · 1/1 new units observable}

Each SLO now owns a hidden slo_burn_rate rule written in the same transaction, whose evaluator judges a critical (1h+5m, 14.4x) and a warning (6h+30m, 6x) tier on their own window pairs through the existing incident engine. The change is safe to merge; the outstanding items are copy and flag-state, not behavior.

• sloRuleFields/evaluateSloBurn write and judge the hidden per-SLO burn rule
• isManagedSignalType hides uptime and SLO rules from the rule APIs and the active cap
• SLO update rewrites its rule and restores one whose row is gone
• Destinations are split per tier and validated against the org

Still open from earlier reviews

• 🔵 Note · F10 · iOS push card reports an SLO page against the rule's 6h window · packages/backend/src/services/alerts/alert-formatting.ts:194
• 🔵 Note · F6 · alerting.enabled reads false for a missing rule, but any edit restores it on · packages/backend/src/services/slos/SlosService.ts:228

Fixed since the last review

• ✅ F11 · No test tells the critical and warning destinations apart, so a swap passes

Production impact

_{fef1f48 · Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}