Add an Uptime Kuma integration: monitor status and which server each one watches

New integration, following the existing pattern: config in-app (URL +
API key, credentials encrypted at rest), its own Uptime Kuma page, an
Integrations list entry, a Dashboard widget, and diagnostic-log/
integration-down-alert coverage for free via the shared withDiagLogging
wrapper. Read-only -- no start/stop equivalent exists for a monitor.

Uptime Kuma has no conventional REST API (the dashboard talks to it over
Socket.IO); researched before writing any code, since guessing wrong here
would have cost real time. The one machine-readable, authenticated
endpoint that lists every monitor is its Prometheus exporter at
GET /metrics, gated by HTTP Basic auth -- an API key as the password with
the username left blank on current installs, or the real dashboard
login on installs from before the API-key feature existed. This adapter
authenticates the same way and parses that endpoint's text-exposition
format itself (metrics: monitor_status, monitor_response_time,
monitor_cert_days_remaining, monitor_uptime_ratio; labels: monitor_id,
monitor_name, monitor_type, monitor_url, monitor_hostname, monitor_port),
verified against the documented metric/label set and the actual upstream
source (server/prometheus.js). A malformed line is skipped rather than
failing the whole scrape.

"What server is being monitored for what": each monitor's target (an IP
for TCP checks, or the hostname out of the URL for HTTP/keyword checks)
is matched against your servers' own IPs and hostnames -- reusing the
same kind of match already used in the consistency report -- and linked
to that server's page. Monitors with no single network target (groups,
push monitors, DNS/keyword checks with a complex URL) are left unmatched
rather than guessed at. Uptime Kuma's tags aren't read, since the
Prometheus endpoint doesn't reliably distinguish a tag label from any
other label it might add later.

The username field is the first genuinely optional integration config
field this app has had; IntegrationField gained an `optional` flag
(server validation and both the add/edit web forms honor it) rather than
special-casing Uptime Kuma.

Verified with 48 backend checks (Prometheus text parsing including
escaped quotes, decimals, negative numbers, and malformed lines; TCP vs.
HTTP target/port extraction; every documented status code; server
matching by IP, hostname, and short name, including no-match cases; the
route's real HTTP round trip against a fake Uptime Kuma server, wrong
credentials, upstream failures, roles, wrong/disabled/missing
integration, diagnostic-log entries; the optional-field validation rule)
and by driving the real page and the real Dashboard widget in a browser
against the real routers, including CSV export and column sorting. Real
dev database mtime untouched.

Not verified: a real Uptime Kuma instance. Everything here was checked
against Uptime Kuma's documented metric format, its actual upstream
source, and a fake server built to match both -- not against a live
installation. If your instance's /metrics output differs from what's
documented (older version, unusual monitor types), the parser should
degrade to an empty or partial monitor list rather than error, but that
degradation itself hasn't been observed against the real thing.

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

README.md

@@ -3,7 +3,7 @@
 Repository: `git@10.200.5.13:bobban/Homelab-manager.git` ([gitea.labsconnect.se/bobban/Homelab-manager](https://gitea.labsconnect.se/bobban/Homelab-manager) externally).
 
 A single dashboard for a homelab: Proxmox, Synology DSM, Semaphore, Tailscale,
-Gitea, and Dockhand/Docker status and basic actions, plus DNS record
+Gitea, Dockhand/Docker, and Uptime Kuma status and basic actions, plus DNS record
 management, an IP address inventory (IPAM), and a secret-expiry tracker
 (ported from [Sloth Manager](../Sloth%20manager)) and scheduled-task tracking
 across Debian/Raspbian hosts (ported from
@@ -35,9 +35,11 @@ All modules from the original plan are built:
   The Domains widget shows how many registrations are tracked, which are
   expired or expiring (soonest first), the next one to expire, and how many
   couldn't be refreshed.
+  The Uptime Kuma widget shows the monitor count, how many are down, and how
+  many are matched to one of your servers.
 - **Diagnostic Log** (admin-only) — every call this app makes to a DNS
   provider or integration (Tailscale, Proxmox, Synology, Semaphore, Gitea,
-  Dockhand), success or failure, with latency and the error message if it
+  Dockhand, Uptime Kuma), success or failure, with latency and the error message if it
   failed — the last 500 calls, filterable by source/result, for
   troubleshooting connectivity issues (ported from Sloth Manager's
   provider-diagnostics log, generalized to cover every integration this app
@@ -77,8 +79,8 @@ All modules from the original plan are built:
   link options") — it stays visible regardless once a server actually is
   linked, so unlinking is always reachable.
 - **Tailscale**, **Proxmox**, **Synology**, **Semaphore**, **Gitea**,
-  and **Docker** each get their own top-level page (backed by the
-  matching integration) instead of living inside a shared Integrations
+  **Docker**, and **Uptime Kuma** each get their own top-level page (backed
+  by the matching integration) instead of living inside a shared Integrations
   browsing view:
   - **Tailscale** — device list with online/authorized status, and
     authorize/deauthorize/remove actions; a live device-count widget.
@@ -102,11 +104,20 @@ All modules from the original plan are built:
     container (from Dockhand's own cached update check, plus a button
     to trigger a fresh one), and a live running/total widget (with an
     updates-available count).
+  - **Uptime Kuma** — every monitor's status (up/down/pending/maintenance),
+    response time, and 24h/30d uptime, with certificate days remaining where
+    applicable. Each monitor is matched to one of your servers when its
+    target (an IP, or a TCP/HTTP hostname) lines up with that server's own
+    address or hostname, linking straight to it — so you can see what's
+    actually being watched on each box, not just a flat monitor list.
+    Uptime Kuma has no conventional REST API (the dashboard talks to it over
+    Socket.IO), so this reads its Prometheus `/metrics` endpoint instead and
+    parses that itself; read-only, no actions.
 
   The Integrations page itself is now just a list of configured
   integrations (name/type/status, visible to every role) with an
   admin-only "Add integration" button and edit/enable/disable/delete
-  actions per row — the six dedicated pages above are where you
+  actions per row — the seven dedicated pages above are where you
   actually use each one.
 - Every table in the app is click-to-sort on any column (numbers, booleans,
   and dates/text sort correctly regardless of how the column formats them)
@@ -142,7 +153,9 @@ assumed HTTPS-only (the NAS is reached over plain HTTP), and the Tailscale
 adapter read `online`/`isExitNode` fields that don't actually exist in the
 real API response (fixed to derive them from `connectedToControl` and
 `enabledRoutes`). See the git log for the full verification notes per
-integration.
+integration. (Uptime Kuma, added later, is not part of that "six" — see
+its own git log entry for what was and wasn't verified against a real
+instance.)
 
 Server and storage health is watched every 15 minutes: a server whose agent
 stops reporting, a server disk / Proxmox storage / Synology volume passing a