Add a Proxmox Backup Server integration: datastore/snapshot verification status

Proxmox VE already shows whether the last vzdump push to PBS succeeded, but
has no visibility into PBS's own backup verification, GC/prune health, or
host status. This adds PBS as its own integration (own adapter, page, nav
entry, and Dashboard widget) that reads datastore usage and, for every
stored snapshot, its verification state directly from PBS.

A new daily check (mirroring the existing Proxmox backup-failure check)
notifies when a snapshot has failed verification or a datastore couldn't be
read, with its own toggle in Settings -> Notifications and its own
maintenance-window silencing.

Not verified against a live PBS instance — built from PBS's published API
docs and a scratch test against a mocked PBS server exercising the adapter's
parsing and auth-header format (PBSAPIToken uses a colon separator, unlike
PVE's PVEAPIToken which uses =). See INTEGRATIONS.md for details and the
"not verified" caveat.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

README.md

@@ -3,7 +3,8 @@
 Repository: `git@10.200.5.13:bobban/Homelab-manager.git` ([gitea.labsconnect.se/bobban/Homelab-manager](https://gitea.labsconnect.se/bobban/Homelab-manager) externally).
 
 A single dashboard for a homelab: Proxmox, Synology DSM, Semaphore, Tailscale,
-Gitea, Dockhand/Docker, and Uptime Kuma status and basic actions, plus DNS record
+Gitea, Dockhand/Docker, Uptime Kuma, and Proxmox Backup Server status and basic
+actions, plus DNS record
 management, an IP address inventory (IPAM), and a secret-expiry tracker
 (ported from [Sloth Manager](../Sloth%20manager)) and scheduled-task tracking
 across Debian/Raspbian hosts (ported from
@@ -37,9 +38,11 @@ All modules from the original plan are built:
   couldn't be refreshed.
   The Uptime Kuma widget shows the monitor count, how many are down, and how
   many are matched to one of your servers.
+  The Proxmox Backup Server widget shows the datastore count and how many
+  stored snapshots have failed verification or were never verified.
 - **Diagnostic Log** (admin-only) — every call this app makes to a DNS
   provider or integration (Tailscale, Proxmox, Synology, Semaphore, Gitea,
-  Dockhand, Uptime Kuma), success or failure, with latency and the error message if it
+  Dockhand, Uptime Kuma, Proxmox Backup Server), success or failure, with latency and the error message if it
   failed — the last 500 calls, filterable by source/result, for
   troubleshooting connectivity issues (ported from Sloth Manager's
   provider-diagnostics log, generalized to cover every integration this app
@@ -80,9 +83,9 @@ All modules from the original plan are built:
   link options") — it stays visible regardless once a server actually is
   linked, so unlinking is always reachable.
 - **Tailscale**, **Proxmox**, **Synology**, **Semaphore**, **Gitea**,
-  **Docker**, and **Uptime Kuma** each get their own top-level page (backed
-  by the matching integration) instead of living inside a shared Integrations
-  browsing view:
+  **Docker**, **Uptime Kuma**, and **Proxmox Backup Server** each get their
+  own top-level page (backed by the matching integration) instead of living
+  inside a shared Integrations browsing view:
   - **Tailscale** — device list with online/authorized status, and
     authorize/deauthorize/remove actions; a live device-count widget.
   - **Proxmox** — VM/LXC status across every node in the cluster, with
@@ -114,11 +117,18 @@ All modules from the original plan are built:
     Uptime Kuma has no conventional REST API (the dashboard talks to it over
     Socket.IO), so this reads its Prometheus `/metrics` endpoint instead and
     parses that itself; read-only, no actions.
+  - **Proxmox Backup Server** — every configured datastore's usage and
+    snapshot count, the PBS host's own CPU/RAM/disk, and each stored
+    snapshot's verification status, since Proxmox VE only knows whether a
+    backup *ran*, never whether PBS's own verify pass on the stored data
+    still passes; a daily check alerts on any snapshot that's failed
+    verification or a datastore that couldn't be read. Read-only, no
+    actions (nothing here can prune, delete, or trigger a re-verify).
 
   The Integrations page itself is now just a list of configured
   integrations (name/type/status, visible to every role) with an
   admin-only "Add integration" button and edit/enable/disable/delete
-  actions per row — the seven dedicated pages above are where you
+  actions per row — the eight dedicated pages above are where you
   actually use each one.
 - Every table in the app is click-to-sort on any column (numbers, booleans,
   and dates/text sort correctly regardless of how the column formats them)
@@ -154,9 +164,10 @@ assumed HTTPS-only (the NAS is reached over plain HTTP), and the Tailscale
 adapter read `online`/`isExitNode` fields that don't actually exist in the
 real API response (fixed to derive them from `connectedToControl` and
 `enabledRoutes`). See the git log for the full verification notes per
-integration. (Uptime Kuma, added later, is not part of that "six" — see
-its own git log entry for what was and wasn't verified against a real
-instance.)
+integration. (Uptime Kuma and Proxmox Backup Server, added later, are not
+part of that "six" — see their own git log entries, and
+[INTEGRATIONS.md](INTEGRATIONS.md), for what was and wasn't verified
+against a real instance.)
 
 Server and storage health is watched every 15 minutes: a server whose agent
 stops reporting, a server disk / Proxmox storage / Synology volume passing a
@@ -225,7 +236,8 @@ workflow or branch, the same as the Gitea page shows.
 
 **Maintenance mode** silences alerts about one server, integration, or DNS
 provider while you work on it (server offline / disk, storage and Synology
-health, Proxmox backup alerts, and "integration down" for that service type).
+health, Proxmox backup alerts, Proxmox Backup Server verification alerts, and
+"integration down" for that service type).
 Every window has a fixed end (5 minutes to 7 days) and expires on its own, and
 a problem that began during a window and is still present when it ends alerts
 then — a forgotten window can't hide an outage. A banner shows what's currently