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/backups.mdx

@@ -0,0 +1,120 @@
+---
+title: Backups
+description: How WHP's automatic backups work, the default-target requirement, full-server backups vs customer data backups, and managing backup targets.
+sidebar:
+  order: 6
+---
+
+import { Aside } from '@astrojs/starlight/components';
+import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
+import AdminSignIn from '~/content/partials/admin-signin.mdx';
+import Support from '~/content/partials/support-link.mdx';
+
+<SuperAdmin />
+
+WHP backs up **customer data** (sites and databases) when an admin has configured a default backup target. WHP does **not** back up the full server — that's a separate concern.
+
+## Two different things called "backup"
+
+It's worth being precise:
+
+- **Customer data backups** — what WHP does. Site files (per user, per domain) and databases. Configured per server via backup targets. These start automatically once a default target exists.
+- **Full server backups** — backing up the host OS, `/etc`, container images, the WHP install itself, etc. **WHP does not do this.**
+
+### Full server backups
+
+| Where WHP runs | Who owns full-server backups |
+|---|---|
+| **Our Virtual Dedicated Server (VDS)** plans | Included. AnHonestHost snapshots the VDS at the platform level. |
+| **Anywhere else** | The server operator. WHP doesn't ship a full-server backup mechanism — you'll need to set up something at the OS / hypervisor level. |
+
+If you're running WHP on your own infrastructure, plan accordingly. WHP's configuration isn't all in `/etc` — there are config and state files in the WHP install directory, in Docker volumes for the platform containers (HAProxy, MySQL, Postgres, Valkey, the WAF), and in service-specific paths elsewhere on the host. The safest approach is a **full-server backup** (image snapshot or filesystem-level backup) rather than trying to enumerate paths.
+
+## Sign in as super admin
+
+<AdminSignIn />
+
+## How customer auto-backups start
+
+**Customer auto-backups don't run until at least one default backup target exists.** A fresh WHP install has no targets and no schedule — every user's backup status is "no targets available" until an admin sets one up.
+
+Once a default target is configured, the platform begins automatic daily backups for every customer with sites or databases. Customers see their own backup history under the [Backups](/whp/how-to/backups/) page in their account.
+
+## The Backup Management page
+
+Sidebar → **Backups**. The admin view of this page mirrors the customer view, with extra controls:
+
+- **Stat tiles** — Total Backups, Total Size, Sites, Databases. Server-wide totals across every account.
+- **Create New Backup** — fires an on-demand backup. Admin form adds a **User** dropdown so you can backup any customer's account, not just your own.
+- **Backup Targets** — the table of destinations available on the server. The **Global** column distinguishes shared targets from per-account targets.
+
+### Backup targets
+
+Each target row has:
+
+- **Name** — your label for the destination.
+- **Type** — S3 (and other supported types) — built-in support for S3-compatible storage (AWS S3, Cloudflare R2, MinIO, etc.).
+- **Connection** — the endpoint URL and bucket / path.
+- **Retention** — how long backups are kept (default 5 days).
+- **Max Backups** — cap on the number of snapshots retained (default 10).
+- **Global** — `Yes` if every account can use this target, `No` if it's bound to a single account.
+- **Actions** — **Test** (verify credentials and write a probe object), **Edit**, **Delete**.
+
+### Adding a global backup target
+
+Click **+ Add Backup Target** and fill in:
+
+1. **Name** — descriptive label.
+2. **Type** — pick S3 (or whichever storage backend you want).
+3. **Endpoint URL** — for non-AWS S3 (Cloudflare R2, MinIO, Wasabi, etc.), point at the provider's endpoint.
+4. **Bucket / path**.
+5. **Access key / Secret** — the credentials WHP will use.
+6. **Retention / Max Backups** — server-wide defaults for any account that uses this target.
+7. **Global** — leave **on** so every account can use it as their default destination.
+
+Click **Test** before saving to confirm WHP can reach the bucket. A good target round-trips a probe object in under a second.
+
+<Aside type="tip">
+  Keep one global target as the default. Customers who want their own offsite (e.g. their own S3 bucket) can add a per-account, non-global target — visible in the same table for the admin, but only usable by that one customer.
+</Aside>
+
+### Per-customer (non-global) targets
+
+Customers can add their own backup targets from the customer-side Backups page. Those show up here with **Global: No** plus a note linking them to the owning account. Admins can edit or delete those on the customer's behalf when they need help.
+
+### Triggering an on-demand backup for a user
+
+In the **Create New Backup** form:
+
+1. Pick the customer in the **User** dropdown.
+2. Pick a **Backup Type** (Sites / Databases / both).
+3. Pick a **Backup Target**.
+4. **Start Backup**. Progress is visible in the run history below.
+
+This is the right path when a customer asks for a fresh backup right before a risky migration.
+
+## Verifying customer backups are succeeding
+
+The Total Backups and Total Size tiles climb over time on a healthy server. If they sit flat:
+
+- Confirm at least one target exists with **Global: Yes**.
+- Open the run history (lower on the page) and look for failed entries — the error message usually points at credentials or quota.
+
+## Troubleshooting
+
+**No backups are running for any customer.** Confirm at least one **Global: Yes** target exists and that its **Test** button returns success. Without a global default, the scheduler doesn't fire.
+
+**One target is failing.** Click **Test** on the target row. The most common causes are rotated credentials, an incorrect endpoint URL (R2 / MinIO often need an explicit endpoint different from AWS's default), or the bucket lifecycle policy deleting backups before the retention window.
+
+**Customer says their backup is too old.** Check **Max Backups** on the target — if it's lower than their backup cadence × retention window, older backups get pruned.
+
+**Backup ran but `tar` step failed mid-stream.** Disk pressure on the host is a common cause. Check **Disk Usage** (admin sidebar) and consider raising the target's retention so fewer backups stack up on the host before upload.
+
+## Related
+
+- [Backups](/whp/how-to/backups/) — the customer-facing side.
+- [Server settings & services](/whp/admin/server-settings/) — including Backup Upload host service.
+
+## Still stuck?
+
+<Support />