docs(admin): rewrite + extend WHP super-admin section from real UI

Verified every page against the live admin panel on whp01 (read-only).
Five existing articles rewritten; one new article added; customer-facing
backups article updated to match server reality.

Article changes
- overview: super admin = the root user only (no UI to add another);
  WHMCS portal route doesn't apply for admin; accurate sidebar map of
  every admin-only section; customer backups don't cover server config
  (multiple locations, not just /etc — full-server backup is the right
  safety net).
- server-settings: walked all six tabs (System / Services / Mail / DNS
  / Network & SSL / Security); clarified that host Apache + PHP-FPM
  serve the WHP control panel, not customer sites; that MySQL runs as
  a container so host MySQL config is client-facing; that custom
  container needs are met by publishing a custom Docker image (linked
  to repo.anhonesthost.net/cloud-hosting-platform/ for examples).
- coraza-waf: real Firing rules / CRS catalog / Activity tabs; global
  WAF mode pill (off/detect/enforce); per-rule + per-host overrides;
  Ask AI link; security.db source-of-truth + SIGHUP reload note.
- site-monitoring: split into the three actual admin pages — AI Monitor
  dashboard, Issues, Ignore Rules — with stat tiles + health-check
  timeline + ignore-rule AND-semantics.
- user-management: account types corrected to full / domain_dns /
  mail_dns (verified in web-files/pages/user-management.php:26);
  system users are protected against deletion (verified is_protected_user
  in web-files/libs/usermgmt.php:697); delegated users are admin-editable
  (not read-only); suspension page is served by haproxy's 503 errorfile
  (verified in haproxy-manager-base/haproxy_tarpit_config.txt:31) so
  troubleshooting points at haproxy reload / container logs.
- new admin/backups: customer-data backups vs full-server backups;
  auto-backups only run with a default target; how to add global vs
  per-customer targets; how to fire on-demand backups for any user;
  troubleshooting around missing targets / failed test / disk pressure.
- how-to/backups (customer): aside about default-target requirement;
  new section explaining what full-server backups cover vs customer
  backups (managed plans + VDS covered by AnHonestHost; elsewhere is
  the server operator's responsibility).

New components / tooling
- admin-signin partial: 'sign in directly at :8443 as root'.
- Head.astro override + medium-zoom: click-to-zoom lightbox on every
  article image; auto-reattaches after Starlight client navigation.
- capture-admin.ts: read-only Playwright capture for admin docs with
  multi-pass redaction (server hostnames, mail server, customer
  domains, customer usernames in table cells, IPs except RFC1918 and
  public resolvers, password/key/token/secret/api input values, plus
  LiteLLM URLs, model names, JWT/sk-prefix API keys, root → admin).

src/content/docs/whp/admin/site-monitoring.mdx

@@ -1,94 +1,112 @@
 ---
-title: Site Monitoring rules
-description: Configure Site Monitoring across every site on the server — global ignore lists, alert routing, and severity tuning.
+title: AI Monitor, Issues & Ignore Rules
+description: The three admin pages that drive the Site Monitoring add-on — AI Monitor dashboard, Issues, and Ignore Rules.
 sidebar:
   order: 4
-  badge:
-    text: Draft
-    variant: caution
 ---
 
 import { Aside } from '@astrojs/starlight/components';
 import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
-import Draft from '~/content/partials/draft-callout.mdx';
-import SignIn from '~/content/partials/signing-in.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
 import Support from '~/content/partials/support-link.mdx';
 
 <SuperAdmin />
 
-<Draft />
+[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting add-on. The admin side exposes three pages — together they let you tune what gets monitored, what surfaces as a customer-visible issue, and what gets suppressed.
 
-[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting product. With super admin access, you can manage the rules that drive those alerts at the server level — including a server-wide ignore list, alert routing, and severity tuning.
+## Sign in as super admin
 
-## Sign in to WHP
+<AdminSignIn />
 
-<SignIn />
+## AI Monitor (admin dashboard)
 
-## Where it lives
+Sidebar → **AI Monitor → Dashboard**. The operational heartbeat of the whole monitoring pipeline.
 
-Sidebar → **Site Monitoring** (admin view). The page shows two perspectives:
+![AI Monitor admin dashboard](~/assets/screenshots/whp/admin-monitor-admin.png)
 
-- **Customer feed** — what your site owners see when they sign in.
-- **Admin tools** — the rule library, global ignore list, and alert configuration.
+Panels:
+
+- **AI Log Monitor Status** — overall on/off plus three sub-statuses:
+  - **Minute-cadence poll** — the cron that scans logs every minute.
+  - **Health API** — the internal API that exposes per-container health.
+  - **HAProxy stats** — the proxy stats feed used for error-rate tracking.
+- **Stat tiles** — Last Run, Errors Tracked, Remediations, API Calls Today (with a rate-limit denominator).
+- **Health Check Timeline (last 7d)** — every state transition (`cpu`, `swap`, `haproxy`, etc.) with its severity and an **AI Diagnosis** explanation.
+
+Use this page to confirm the pipeline is healthy and to drill into recent state changes. The AI Diagnosis text gives a plain-language summary of *why* a transition happened — useful for context before you act.
+
+## Issues
+
+Sidebar → **AI Monitor → Issues**. The customer-visible findings, server-wide.
+
+![Issues page](~/assets/screenshots/whp/admin-issues.png)
+
+Four stat tiles at the top:
+
+- **Critical** — open critical-severity issues.
+- **Warning** — open warning-severity issues.
+- **Auto-resolved (review)** — issues the monitor closed on its own that may still need a human glance.
+- **Active suppressions** — issues currently muted by an Ignore Rule.
+
+Filter row: Scope (All / specific user), Status (Open / Closed / All), Severity, Source, Signature prefix.
+
+Bulk actions: **Mark Fixed**, **Ignore**, **Delete**.
+
+Each row has its own quick-actions: **Fix** (close it) and **Ignore** (create an ignore rule from this row's match criteria).
+
+## Ignore Rules
+
+Sidebar → **AI Monitor → Ignore Rules**. Match criteria that prevent matching findings from becoming customer-visible issues.
+
+![AI Monitor Ignore Rules page](~/assets/screenshots/whp/admin-ignore-rules.png)
+
+Each rule has these fields:
+
+- **Scope** — `user` (just one customer) or `global` (every customer).
+- **Target** — the user or domain the rule applies to.
+- **Match** — a comma-separated set of `field=value` predicates (e.g. `cat=degraded & title~"Beaver Builder cache files missing"`). Match fields combine with **AND** semantics — every predicate must match.
+- **Reason** — a short note for future-you explaining why the rule exists.
+- **Hits / Last hit** — how often the rule has matched, and when.
+- **Enabled** — toggle without deleting.
+
+<Aside type="tip">
+  Prefer **per-user** ignores over global. Global rules silence the finding for everyone on the server.
+</Aside>
 
 ## Common tasks
 
-### Add a global ignore rule
+### Mute a known-noisy finding for one customer
 
-When a signature is noisy for every site (for example, a known scanner you allow on your own infrastructure):
+1. Open **Issues**, find the row.
+2. Click the row's **Ignore** action — that pre-fills an Ignore Rule with the matching criteria scoped to that user.
+3. Add a **Reason** so future-you (or someone else on the team) understands why it exists.
+4. Save. Future matching findings will be suppressed; the **Active suppressions** tile will tick up.
 
-1. Open **Site Monitoring → Global Ignore Rules**.
-2. Click **Add Rule**.
-3. Define the match condition (rule_id, source IP/CIDR, URL pattern, or a combination).
-4. Add a short note so future-you remembers why this exists.
-5. Save. Matching events stop firing alerts immediately.
+### Investigate an "Auto-resolved (review)" issue
 
-<Aside type="caution">
-  Global ignore rules silence every site on the server. Prefer per-site ignore (set in the customer-facing Site Monitoring page) when the noise is site-specific.
-</Aside>
+These are issues where the underlying signal recovered before a human looked at them. Open the row to see the AI Diagnosis and the original detection. If the resolution looks legitimate, click **Mark Fixed**; if you're suspicious, leave it open and add a comment for context.
 
-### Tune severity for a rule
+### Tune brute-force detection
 
-If a rule is set to **critical** but you've decided it's really informational in your environment:
+Brute-force rules live in **Coraza Rules** (rule families CRS-913 / 921 / 942 / 949) rather than AI Monitor. AI Monitor surfaces the *effects* (error spikes) once a brute-force pattern fires, but the matching itself is in the WAF — see [Coraza WAF rules](/whp/admin/coraza-waf/).
 
-1. Find the rule in **Site Monitoring → Rules**.
-2. Open the rule and change its severity to one of: informational / warning / critical.
-3. Save. The severity change applies to new events from that rule.
+## Routing alerts
 
-Severity matters because **SMS notifications fire only on critical**. Downgrading from critical to warning silences SMS without silencing the rule.
-
-### Route alerts somewhere other than the default
-
-Default routing: alerts go to the contact email on the account. You can:
-
-- **Add additional email recipients** — useful for a shared ops alias.
-- **Enable SMS for critical alerts** — wire your phone number on the **Alert Routing** page.
-- **Forward to a webhook** — for integration with Slack, PagerDuty, or your own incident pipeline.
-
-## Brute-force detection
-
-Brute-force detection is a separate rule family and has its own per-site sensitivity. From the admin view, you can adjust:
-
-- The window in which repeated failures count.
-- The threshold at which the rule fires.
-- Whether the rule auto-blocks the source IP (recommended) or only alerts.
-
-## Things to know
-
-- **Ignore lists don't stop logging.** They only suppress alerts. The events still appear in the audit feed so you can see what's actually happening.
-- **Rules apply on the next log scan**, typically within a minute.
-- **A muted rule for one customer doesn't affect others.** Per-site ignore is scoped tightly.
+Customer email alerts are sent via the SMTP relay configured on **Server Settings → Mail → Outbound Email (SMTP)**. Toggle **Enable Outbound Email** off there if you need to silence outbound notifications for a maintenance window.
 
 ## Troubleshooting
 
-**No alerts arriving for a known event.** Check the **Global Ignore Rules** list and any per-site ignores. Also confirm the rule's severity isn't set to informational (no email or SMS by default).
+**Pipeline shows "stale" — Last Run more than a few minutes ago.** Check the cron's container on **Server Settings → Services → Docker Container Management**. The monitor poll is `whp-monitor-poll`.
 
-**SMS not firing on critical.** Confirm SMS is enabled in **Alert Routing** and the phone number is verified.
+**Issues appearing for a known noisy site.** Add an Ignore Rule scoped to that user.
+
+**No customer alerts arriving.** Confirm Outbound Email is enabled and the SMTP relay is reachable from the server.
 
 ## Related
 
-- [Site Monitoring add-on](/whp/add-ons/monitoring/) — what the customer sees.
-- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall, complements monitoring.
+- [Site Monitoring add-on](/whp/add-ons/monitoring/) — the customer-facing side.
+- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall.
+- [Server settings & services](/whp/admin/server-settings/) — SMTP relay config for outbound alerts.
 
 ## Still stuck?