homepage: three cards could never be green, and one of them was lying

The board showed mariadb, valkey and Postgres as "down". None of them is down:
the checker runs on Dankclaw and can reach that host's loopback, its container
names, and published LAN addresses — while all three cards probe
container-internal database ports (192.168.0.235:3306, 127.0.0.1:6379/:5432).
They were red by construction, which is how a status board stops being read.
Publishing a database port on the LAN to make a badge green is not a trade this
fleet makes, so they are wip with the reason in their description, and the apps
that front them carry the status. Gluetun (WireGuard, UDP) was the pre-existing
example of the same call.

The rule is now written down in the Homepage doc: a card must be probeable from
the monitor's host or be wip. That is the same lesson as the Prometheus jobs
that scrape HTML pages and can never report up — an always-red signal teaches
the operator to ignore the surface it lives on.

serverAppConfigs-docs/Infrastructure/Homepage.md

@@ -186,6 +186,21 @@ agent knowledge base (`~/.pi/agent/docs/caddy/caddyfile.md`).
 - `probe` — the backend `host:port` the checker probes.
 - `method` — `tcp` or `http`. The probe type for this service (Q10).
 - `wip` — when true, the badge shows WIP and the checker skips the probe.
+
+**A card must be probeable from the monitor's host, or it must be `wip`.** The
+checker runs on Dankclaw, so its reach is: that host's own loopback, its own
+container names, and LAN addresses that are actually *published*. A card whose
+probe is a container-internal port of another host can never turn green — it
+reports a red dot for a healthy service, which is how the board stops being
+worth reading (the same lesson as the Prometheus jobs that scrape HTML pages).
+
+Three cards were exactly that until 2026-09-16 — `mariadb`
+(`192.168.0.235:3306`), `valkey` and `Postgres` (`127.0.0.1:6379`/`:5432`) — all
+probing unpublished database ports. Publishing a database on the LAN to make a
+badge green is not a trade this fleet makes, so they are `wip` with the reason in
+their description, and the app that fronts each database carries the status
+(Glutun, a WireGuard UDP service, was the pre-existing example of the same
+call).
 - `showLink` — when false, the panel shows status only (no "Open" link).
 
 ## Deployment and testing

shared/homepage/services.json

@@ -120,7 +120,6 @@
     "wip": false,
     "showLink": true
   },
-
   {
     "name": "Hermes",
     "category": "admin",
@@ -245,23 +244,23 @@
   {
     "name": "mariadb",
     "category": "admin",
-    "description": "The media-stack database.",
+    "description": "RomM's database (Dankserver). Not probeable from the monitor: 3306 is container-internal, and publishing a database port on the LAN is not a trade this fleet makes. RomM's own card covers the stack.",
     "url": "",
     "docs": "",
     "probe": "192.168.0.235:3306",
     "method": "tcp",
-    "wip": false,
+    "wip": true,
     "showLink": false
   },
   {
     "name": "valkey",
     "category": "admin",
-    "description": "The SearXNG cache.",
+    "description": "SearXNG's cache/limiter (Dankclaw). Not probeable: 6379 is container-internal. SearXNG's own card covers the stack.",
     "url": "",
     "docs": "",
     "probe": "127.0.0.1:6379",
     "method": "tcp",
-    "wip": false,
+    "wip": true,
     "showLink": false
   },
   {
@@ -322,12 +321,12 @@
   {
     "name": "Postgres",
     "category": "admin",
-    "description": "The Gitea database.",
+    "description": "Authentik's and Gitea's databases (Dankclaw). Not probeable: 5432 is container-internal. Their apps' cards cover the stacks.",
     "url": "",
     "docs": "",
     "probe": "127.0.0.1:5432",
     "method": "tcp",
-    "wip": false,
+    "wip": true,
     "showLink": false
   },
   {