feat(dashboard): replace 24h charts with Configuration Status and Recent Activity (#785)

* feat(dashboard): replace 24h charts with Configuration Status and Recent Activity

The 24-hour CPU/Memory area charts summed per-container metrics normalized
to each container's CPU quota, producing numbers that bore no honest
relationship to host load. The live ResourceGauges strip already shows
accurate host-level stats, making the historical charts both inaccurate
and redundant.

This commit replaces that row with two side-by-side cards:

- **Configuration Status**: aggregates every toggleable feature on the
  active node (notification agents, alert rules, routing rules, auto-heal,
  auto-update, webhooks, scheduled tasks, MFA, SSO, vulnerability scanning,
  cloud backup, and alert thresholds) into a single at-a-glance card.
  Tier-locked rows display an upgrade indicator instead of a value.
  Each row is clickable and navigates to the relevant settings section.
  Data refreshes every 60 s and immediately on state-invalidate events.

- **Recent Activity**: lists the ten most recent notification-history events
  for the active node (deployments, image updates, auto-heal actions, scan
  findings, cloud backup events, system notices) with category icons and
  relative timestamps. Refreshes every 30 s.

New backend endpoints:
- GET /api/dashboard/configuration - per-node feature status with locked/
  requiredTier markers so the frontend renders upgrade chips without extra
  calls. The endpoint sits after authGate and before the remote proxy so
  remote-node requests are transparently forwarded.
- GET /api/dashboard/recent-activity?limit=N - thin wrapper over
  DatabaseService.getNotificationHistory.
- GET /api/fleet/configuration - fleet-wide fan-out using the same
  Promise.allSettled dead-node-tolerant pattern as /fleet/overview.
  Exposed as the new "Status" tab on the Fleet page (after Snapshots).

Shared utilities:
- visibilityInterval and formatCount extracted to frontend/src/lib/utils.ts
  so the three polling hooks and two components share a single copy.

* docs(dashboard): fix stale alt text referencing removed historical charts

docs/features/dashboard.mdx

@@ -1,12 +1,12 @@
 ---
 title: Dashboard
-description: Real-time system stats, stack health, historical metrics, and recent alerts for your host machine.
+description: Real-time system stats, stack health, configuration overview, and recent activity for your active node.
 ---
 
-The **Home** tab is the first thing you see after logging in. It provides a live overview of your node's health, resource usage, stack status, and recent alert activity.
+The **Home** tab is the first thing you see after logging in. It provides a live overview of your node's health, resource usage, stack status, active configuration, and recent activity.
 
 <Frame>
-  <img src="/images/dashboard/dashboard-overview.png" alt="Sencho dashboard showing status masthead, unified gauge strip, stack health table, and historical charts" />
+  <img src="/images/dashboard/dashboard-overview.png" alt="Sencho dashboard showing status masthead, unified gauge strip, and stack health table" />
 </Frame>
 
 ## Status masthead
@@ -57,18 +57,58 @@ A mono table of every stack discovered in your `COMPOSE_DIR`, sorted by load so
 
 Warning rows take on a subtle amber wash; critical rows take on a rose wash. Click any row to jump to that stack's editor. If you have more than 8 stacks, the list paginates automatically.
 
-## Historical charts
+## Configuration Status
 
-Two area charts display time-series data sampled at one-minute intervals, retained for up to 24 hours:
+The Configuration Status card gives you an at-a-glance view of every toggleable automation and security feature on the active node, so nothing is silently off when you expect it to be on.
 
-- **CPU** - normalized total CPU percentage across all managed containers over host cores, stroked in cyan with the peak highlighted in amber.
-- **Memory** - total memory allocated by managed containers in GB.
+<Frame>
+  <img src="/images/dashboard/configuration-status.png" alt="Dashboard showing the Configuration Status card on the left and the Recent Activity feed on the right" />
+</Frame>
 
-Hover over a data point to see the exact value at that moment.
+The card is divided into four sections:
 
-<Note>
-  Charts only show data from the moment Sencho started collecting. If you just installed Sencho, they will be mostly empty until metrics accumulate.
-</Note>
+### Notifications & Alerts
+
+| Row | What it shows |
+|-----|---------------|
+| **Notification agents** | Which delivery agents (Discord, Slack, custom webhook) are configured and enabled |
+| **Alert rules** | Number of per-stack alert rules in effect |
+| **Notification routing** | Number of enabled routing rules that direct specific categories to specific agents |
+
+### Automation
+
+| Row | What it shows |
+|-----|---------------|
+| **Auto-heal policies** | Enabled and total crash-recovery policies across all stacks |
+| **Auto-update stacks** | Stacks enrolled in automated image-update checks |
+| **Webhooks** | Outbound webhook triggers that fire on stack events |
+| **Scheduled tasks** | Active scheduled operations (backups, restarts, scripts) |
+
+### Security
+
+| Row | What it shows |
+|-----|---------------|
+| **MFA** | Whether multi-factor authentication is set up for your account |
+| **SSO** | Whether single sign-on is enabled and the active provider |
+| **Vulnerability scanning** | Number of enabled scan policies |
+
+### Backups & Thresholds
+
+| Row | What it shows |
+|-----|---------------|
+| **Cloud Backup** | Active cloud backup provider (or Disabled) |
+| **Alert thresholds** | Current CPU, RAM, and disk alert thresholds |
+| **Crash detection** | Whether global crash detection is active |
+
+**Click any row** to jump directly to the settings section that manages it.
+
+Rows for features locked to a higher tier are shown in a muted state with an upgrade indicator. The data refreshes automatically every 60 seconds and updates immediately when any setting changes.
+
+## Recent Activity
+
+The Recent Activity feed, to the right of Configuration Status, shows the ten most recent events on the active node: deployments, image updates, auto-heal actions, vulnerability scan results, cloud backups, and system notices. Each entry shows a category icon, the event message, and a relative timestamp.
+
+If no activity has been recorded yet, the feed shows an empty state.
 
 ## Recent alerts
 

docs/features/fleet-view.mdx

@@ -37,10 +37,11 @@ Below the masthead, switch between two layouts:
 
 ### Tabs
 
-The Fleet page has two tabs:
+The Fleet page has three tabs:
 
 - **Overview**: the monitoring view described on this page
 - **Snapshots**: fleet-wide backup snapshots (covered in [Fleet Backups](/features/fleet-backups))
+- **Status**: fleet-wide feature status rollup (covered below)
 
 ### Action buttons
 
@@ -176,6 +177,33 @@ If you update the local node, a confirmation dialog appears first, then a reconn
 
 ---
 
+## Fleet Status tab
+
+The **Status** tab gives you a fleet-wide summary of which automations and security features are active on each node, without having to open each node's settings individually.
+
+<Frame>
+  <img src="/images/fleet/configuration-tab.png" alt="Fleet Configuration tab showing per-node configuration summaries with one online node and one offline node" />
+</Frame>
+
+Each node appears as a card. Online nodes display a compact two-column summary grid:
+
+| Field | What it shows |
+|-------|---------------|
+| **Agents** | Delivery agents configured on this node |
+| **Alert rules** | Number of per-stack alert rules |
+| **Auto-heal** | Active auto-heal policies |
+| **Webhooks** | Outbound webhook triggers |
+| **MFA** | Whether MFA is set up for the admin account |
+| **Scanning** | Active vulnerability scan policies |
+| **Backup** | Cloud backup provider, or Disabled |
+| **Crash detect** | Whether global crash detection is on |
+
+Offline nodes show a muted card with "Node is unreachable. Configuration unavailable." The online/offline badge confirms the node's current reachability at the time of the last fetch.
+
+The tab fetches configuration data from all nodes in parallel. A dead node does not block the others from rendering.
+
+---
+
 ## How fleet data is fetched
 
 Fleet View queries all registered nodes in parallel. Each node responds independently; one slow or offline node does not block the others. Local node data comes from the Docker socket and system stats directly. Remote node data is fetched over the Distributed API proxy using each node's Bearer token.