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>

INTEGRATIONS.md

@@ -57,6 +57,24 @@ the dashboard views themselves load fine.
 - **Actions used:** list environments/containers, check for image updates, start/stop/restart a container
 - **Required access:** A Dockhand API token belonging to a user with access to every environment (Docker host) you want visible, with permission to **start/stop/restart containers and trigger update checks** in each — not just view them.
 
+### Uptime Kuma
+
+- **Config fields:** Uptime Kuma URL, username (leave blank — see below), API key
+- **Auth:** HTTP Basic, with the API key as the password and the username left empty. Uptime Kuma has no
+  conventional REST API — the dashboard talks to it over Socket.IO — so this integration reads its
+  Prometheus-metrics endpoint (`GET /metrics`) instead and parses that. On installs from before the API-key
+  feature existed (Uptime Kuma < 1.23), that endpoint instead checks your real dashboard login, so put your
+  Uptime Kuma username and password in those two fields rather than leaving the username blank.
+- **Required access:** In Uptime Kuma, go to Settings → API Keys → **Add API Key**, and paste the value it
+  shows you (once — it isn't shown again) into this integration's "API key" field. No other permission is
+  needed; the metrics endpoint is read-only.
+- **What you get:** every monitor's status (up/down/pending/maintenance), response time, uptime over 24
+  hours/30 days, and certificate days remaining where applicable. A monitor is linked to one of your servers
+  when its target — an IP, or a TCP/HTTP hostname — matches that server's own address or hostname; monitors
+  with no single network target (groups, push monitors, keyword checks with a complex URL) are shown
+  unmatched rather than guessed at. Uptime Kuma's tags aren't read, since the metrics endpoint doesn't
+  reliably distinguish a tag from any other label.
+
 ## DNS providers
 
 ### Cloudflare