Add native Slack notification module

[hostarts]

Summary

Adds first-class Slack delivery alongside the existing email path. Until now, posting backup results to Slack required wrapping vmbackup.sh in ExecStopPost or a cron post-hook, which only sees the systemd $SERVICE_RESULT/$EXIT_STATUS and has to re-derive session totals from the DB out-of-band. With this PR, Slack posts use the same sqlite_query_session_summary row the email module uses, fire from the same four call sites (so failure-path notifications still go out when a run aborts before normal end-of-main), and stay enabled/disabled independently of email.

What changed

• modules/slack_notification_module.sh (new): load_slack_config() + send_slack_notification() mirroring load_email_config() / send_backup_report(). Posts a coloured attachment with VM totals (ok / failed / skipped / excluded), total bytes, duration, and instance name. JSON is built inline; only runtime dependency is curl.
• config/template/slack.conf (new): SLACK_ENABLED, SLACK_WEBHOOK_URL, SLACK_HOSTNAME, SLACK_TITLE_PREFIX, SLACK_ON_SUCCESS, SLACK_ON_FAILURE, SLACK_TIMEOUT. Independent flags so Slack-only / email-only / both are all valid combinations.
• vmbackup.sh: wired Slack into the same four sites as email — cleanup_on_exit (pre-flight aborts), handle_sigterm (systemd timeout / manual stop), the replicate-only mode end, and the normal session end in main. _SLACK_SENT guard prevents duplicate posts the same way _EMAIL_SENT does.
• CHANGELOG.md: [Unreleased] entry under ### Added.

Design notes

• Mirrors email rather than replacing it. Same enable/condition gates (*_ON_SUCCESS/*_ON_FAILURE), same call sites, same data source. Operators who already understand the email config don't have to learn a new mental model.
• No new dependencies beyond curl. No jq. JSON is escaped with a small in-module helper (_slack_json_escape) so the module can drop into an existing AlmaLinux/Debian install with no extra packages.
• Falls back gracefully. If SQLite isn't available, the post still goes out with zeroed totals — the operator still gets the success/failure signal.
• Default-off. SLACK_ENABLED=\"no\" in the template; no behaviour change for existing installs.

Test plan

• bash -n vmbackup.sh + bash -n modules/slack_notification_module.sh pass.
• load_slack_config round-trips a minimal slack.conf (smoke-tested locally).
• _slack_format_bytes produces TiB/GiB/MiB/KiB/B with correct boundaries.
• Verified the four vmbackup.sh integration sites match the four corresponding email sites (grep confirms 4×send_slack_notification next to 4×send_backup_report).
• End-to-end run on real backup hosts (verified in operator environment, not part of this PR).

🤖 Generated with Claude Code

[doutsis]

Thanks for this, @hostarts — really clean work, and mirroring the email module's shape (same call sites, same data row, default-off, no new deps beyond curl) made it easy to take.

Heads-up on how it's landing: doutsis/vmbackup is a publish mirror — development happens in a separate private tree and is synced out one-way at release time, so I can't merge directly here without the next sync reverting it. So I've brought your contribution into the dev tree against the current 0.6.1 line instead. It ships in 0.6.1 and will appear here automatically with that release.

A couple of small adaptations on the way in: the four notification hooks now route through the current _handle_notifier_rc-style dispatcher (the 3-way delivered/skipped/failed handling that landed after your branch was cut), and I added a parity gate (asserts Slack fires from the same sites as email) plus a mock-webhook smoke test so CI can verify the payload without a live Slack workspace. Your authorship is credited in the module header, both slack.conf files, and the CHANGELOG.

I'm going to close this PR since it can't be merged against the mirror — that's purely a workflow artefact, not a rejection; the feature is in. Thanks again for contributing it.