Surface Proxmox backup job status, with a daily failure notification

Proxmox already runs vzdump backups, but nothing in the app said
whether they were actually succeeding — a silent backup failure is
one of the more dangerous blind spots a homelab admin can have. Adds
a "Backups" card to the Proxmox page: configured backup job
schedules (storage target, which guests, enabled/disabled) from
GET /cluster/backup, and recent vzdump task history per node from
GET /nodes/{node}/tasks?typefilter=vzdump, with a banner at the top
if the most recent run didn't succeed.

New "Proxmox backup failed" notification toggle under Settings ->
Notifications, on the same daily schedule as the other checks. The
scheduler checks each node's own most-recent vzdump run independently
(not just the single most recent task overall) so one node's healthy
backup can't mask another node's failing one in a multi-node cluster.

Known limitation, documented in the adapter's own header comment:
Proxmox's task list doesn't reliably expose which specific guest
failed within an "all guests" job — only the task's own log text has
that — so this surfaces job- and task-level status rather than
guessing at per-guest outcomes.

Verified against a fake Proxmox server (real self-signed HTTPS, since
the adapter's node:https usage can't be monkey-patched under ESM)
reproducing the documented /cluster/backup and task-list response
shapes: job parsing (all-guests+exclude vs specific-vmids+disabled)
correct, task OK/failure parsing correct, and the critical multi-node
scenario confirmed — one node's failing latest run flagged, the
other's healthy latest run correctly left alone, with exactly one
notification of the right content. This reproduces Proxmox's
documented API shape rather than a live-verified one; flag if the
real cluster's response differs in some way this didn't anticipate.
Confirmed the real dev database's mtime was untouched throughout.

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

web/src/api/client.ts

@@ -153,6 +153,7 @@ export interface NotificationEvents {
   secretCheck: boolean;
   tailscaleKeyCheck: boolean;
   dockerUpdateCheck: boolean;
+  proxmoxBackupCheck: boolean;
   secretCheckTime: string;
   timezone: string;
   integrationFailureAlerts: boolean;
@@ -509,6 +510,32 @@ export interface ProxmoxNodesResponse {
   nodes: ProxmoxNodeStats[];
 }
 
+export interface ProxmoxBackupJob {
+  id: string;
+  enabled: boolean;
+  schedule: string;
+  storage: string;
+  node: string | null;
+  allGuests: boolean;
+  vmids: string | null;
+  exclude: string | null;
+}
+
+export interface ProxmoxBackupTask {
+  node: string;
+  upid: string;
+  guestId: string | null;
+  status: string;
+  ok: boolean;
+  startTime: string;
+  endTime: string | null;
+}
+
+export interface ProxmoxBackupsResponse {
+  jobs: ProxmoxBackupJob[];
+  tasks: ProxmoxBackupTask[];
+}
+
 export interface SynologyVolume {
   id: string;
   status: string;
@@ -826,6 +853,7 @@ export const api = {
     proxmox: {
       guests: (integrationId: number) => request<ProxmoxGuestsResponse>(`/api/integrations/${integrationId}/proxmox/guests`),
       nodes: (integrationId: number) => request<ProxmoxNodesResponse>(`/api/integrations/${integrationId}/proxmox/nodes`),
+      backups: (integrationId: number) => request<ProxmoxBackupsResponse>(`/api/integrations/${integrationId}/proxmox/backups`),
       start: (integrationId: number, node: string, type: ProxmoxGuestType, vmid: number) =>
         request<void>(`/api/integrations/${integrationId}/proxmox/nodes/${node}/${type}/${vmid}/start`, { method: "POST" }),
       stop: (integrationId: number, node: string, type: ProxmoxGuestType, vmid: number) =>