feat(lightning): add ThunderHub health endpoint for monitoring

[TaprootFreak]

Was

Neuer Endpoint GET /v1/thunderhub/health — gibt 200 { "up": true } wenn der upstream-ThunderHub-Container erreichbar ist, 503 wenn nicht.

Warum

Aus der DFX-Server-Migration (DFXServer/server, Stage 2.1 live seit 2026-05-08): Uptime Kuma hat 14 LDS-DEV-Monitore, alle nach demselben Pattern — https://dev.lightning.space/v1/<path>, mit lds-api als Forwarder zu lnbits / boltz-backend / claim-graphql.

ThunderHub war der einzige LDS-Service ohne Kuma-Coverage, weil:

• Container ist nur intern via nginx auf 127.0.0.1:6123 exposed (SSH-Tunnel-Only Access für Operatoren)
• Cloudflare-Tunnel zeigt nur auf lds-api (http://localhost:6125), nicht auf nginx

Ergebnis: mehrfach hat erst ein toter Tunnel-Reconnect des thunderhub-remote-Skripts dem Operator gezeigt, dass der Container über Stunden down war.

Konsistent zu den existing 13 Monitoren ist der Probe via lds-api. Dieser PR fügt diesen Endpoint hinzu.

Wie

@Get('health')
async health(): Promise<{ up: true }> {
  const url = Config.blockchain.lightning.thunderhub.apiUrl;
  if (!url) throw 503;
  try {
    await this.http.request({ url, method: 'GET', responseType: 'text', timeout: 5000,
      validateStatus: (status) => status >= 200 && status < 500 });
    return { up: true };
  } catch (e) {
    throw 503; // mit Error-Body
  }
}

• validateStatus: 2xx-4xx heisst: ThunderHub-Login-Redirect (302) oder 401-Forderung wird als UP gewertet — wir prüfen Erreichbarkeit, nicht Auth-Status.
• 5s Timeout — kurz genug damit Kuma DOWN binnen eines Probe-Intervalls sieht.
• Kein Body-Leak: Endpoint gibt nur {up: true} oder {up: false, error} zurück, niemals Upstream-Inhalt.
• Kein Auth: Endpoint exposed nur einen Boolean, keine internal state.

Konfiguration

Neue env-var LIGHTNING_THUNDERHUB_URL in den 4 Vault-Items:

• LDS DEV - API Environment Variables (Org DFX-dev-infra) → http://thunderhub:3000
• LDS PRD - API Environment Variables (Org DFX-prd-infra) → http://thunderhub:3000

Default ist leer → Endpoint antwortet 503 mit LIGHTNING_THUNDERHUB_URL not configured. Damit ist es safe wenn die Vault-Items vor dem Vault-Update bereits ge-mergt sind.

Test plan

• nest build kompiliert ohne Errors
• Prettier sauber, ESLint sauber
• Nach DEV-Deploy: curl https://dev.lightning.space/v1/thunderhub/health → 200 {"up":true}
• Test DOWN-Pfad: docker stop lds-thunderhub-1 → curl ... → 503 mit Error
• Kuma-Monitor "LDS - thunderhub - DEV" hinzufügen (separater Schritt im DFXServer/server)

Sicherheit

• Kein Privat-Material berührt. Endpoint exposed nur up/down Boolean.
• Konsistent zu den existing 13 lds-api-forwarders, die alle die selbe HttpService-Pattern nutzen.