Summary

Follow-up to #3218 (review feedback): adds regression tests pinning the global-fallback match arm in LibreFangKernel::push_notification so a future refactor cannot silently disable heartbeat alerts. No production code changes.

Per CLAUDE.md "always write integration tests at the injection site" — the parent PR wired health_check_failed into notification.alert_channels via a one-line match arm extension; this PR locks the contract.

What's covered

Four tests, all calling LibreFangKernel::push_notification directly with a RecordingChannelAdapter (pattern lifted from test_notify_escalated_approval_prefers_request_route_to):

1. health_check_failed falls back to alert_channels when no agent_rule matches — the core wiring from feat(kernel/heartbeat): deliver HealthCheckFailed to notification.alert_channels #3218.
2. A matching agent_rule overrides alert_channels — pins routing precedence so per-agent overrides can't be regressed by future global-fallback edits.
3. No configured targets → zero sends — heartbeat must stay silent rather than panic when an operator hasn't configured [notification.alert_channels] at all.
4. Unknown event_type yields zero targets — a typo in event_type must never accidentally page operators via the global fallback.

Why this shape

push_notification is a private async method, but the resolver logic (agent_rules match → fallback to event-type-keyed global channels) is a pure routing decision over (NotificationConfig, agent_id, event_type). Driving the real method end-to-end through a recording adapter gives us the same lock without extracting a free function — and matches how test_notify_escalated_approval_prefers_request_route_to already pins approval routing.

Out of scope (separate follow-ups)

• Live supergroup-style end-to-end test for the heartbeat → Telegram path. Not done here; remains the operator's responsibility before relying on this in prod (the box was unchecked in feat(kernel/heartbeat): deliver HealthCheckFailed to notification.alert_channels #3218's body).
• Docs drift cleanup: docs/configuration/core/page.mdx [notification] section uses old field names (kind/target/agent/targets) vs the actual schema (channel_type/recipient/agent_pattern/channels/events), and health_check_failed isn't enumerated as a valid events entry. Worth a separate docs-only PR.

Test plan

• cargo test -p librefang-kernel --lib kernel::tests::test_push_notification — 4 passed.
• cargo clippy -p librefang-kernel --lib --tests -- -D warnings — clean.