feat: alert on Telegram/Discord when a host has OS updates waiting

[FMSMITH91]

You asked to be told when the panel server or a remote has system updates. The panel already knew how to check both — os_update_available for the panel host, remote_os_check_updates over SSH — but only ever when someone opened a page and looked.

New os_updates event, on by default, toggleable in Notification settings like every other alert.

Security updates on Panel Server
2 security updates of 3 waiting on Panel Server: openssl, curl

Design decisions worth flagging

Once a day, not every tick. Each check runs apt update — a network fetch on every host. It rides the existing 30-minute ticker (which already does panel-update and TLS-expiry alerts) rather than adding another thread, and self-throttles to 24h from there.

It alerts on the transition, and re-arms when the host is patched. Being told every morning that the same twelve packages are still waiting is how an alert becomes something you filter out — which is the exact failure this session started with.

Security updates are called out separately. Both parsers dropped the apt suite (jammy-security), the one field that distinguishes a security update. They now keep it as an additive key, so existing callers are untouched.

An unreachable host is skipped, not probed — that's the monitor's alert to raise, not this one's.

Tests

Ten checks drive the real function with stubbed hosts. Two were worthless when I first wrote them, and mutation testing said so:

• the throttle check ran with the host already alerted, so the transition guard hid it — removing the throttle changed nothing
• the "not probed" check asserted silence, which a swallowed exception provides anyway — it passed with the guard deleted

Both rebuilt to assert the thing itself. All four guarantees now fail under mutation: transition, throttle, security detection, and skipping unreachable hosts.

unit 892 · smoke 313 → 323 · rbac 65 · manage 21 · template_actions 7 · lint clean.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 duplication

Metric	Results
Duplication	0

View in Codacy

🟢 Coverage 66.67% diff coverage · +0.03% coverage variation

Metric	Results
Coverage variation	✅ +0.03% coverage variation (-1.00%)
Diff coverage	✅ 66.67% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a319006)	Report Missing	Report Missing	Report Missing
Head commit (2f7307a)	11999 (+34)	5911 (+20)	49.26% (+0.03%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#80)	36	24	66.67%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}