Calibrate notification severity taxonomy and Critical thresholds

Split from #3214 after validation.

## User symptom
Some operational disruptions feel over-labelled as Critical, for example airport-delay style alerts that do not warrant the highest severity.

## Validation notes
- Realtime delivery currently narrows to Critical only, making Critical the only immediate-notification tier for many users.
- Relay sensitivity is effectively `all`, `high`, or `critical`, and legacy severity matching is binary around high/critical.
- Importance-score thresholds exist only when `IMPORTANCE_SCORE_LIVE=1` and only when events carry `payload.importanceScore`.
- Aviation notification mapping marks `FLIGHT_DELAY_SEVERITY_SEVERE` as `critical` and `MAJOR` as `high`; this may be reasonable for closures but needs explicit thresholds and product language for severe delays versus true critical events.

## Scope
- Define a clear severity hierarchy: informational, low, medium, high, critical.
- Define strict Critical thresholds by domain. Critical should mean immediate action or major operational/geopolitical impact, not merely inconvenient delay.
- Audit current notification publishers for severity mapping, especially aviation, weather, cyber, conflict, RSS alerts, and OREF.
- Decide whether realtime should support High notifications again, or whether Critical should remain very rare and tightly defined.
- Add tests for representative borderline cases.

## Acceptance criteria
- Critical mapping is documented and enforced per domain.
- Minor/moderate airport delay scenarios cannot produce Critical notifications.
- Severe airport closure or ground-stop scenarios still produce appropriate high/critical alerts based on explicit thresholds.
- Notification settings labels match the taxonomy users see in delivered alerts.

Start by auditing the current notification publishers, with particular attention to aviation, weather, cyber, conflict, RSS, and OREF mappings, then inspect how realtime delivery and relay sensitivity interpret severity. Define and document domain-specific Critical thresholds, add representative borderline-case tests, and verify that settings labels match delivered alerts.

Written by the indexing model from the issue text.