feat(cluster): GUI-Repair-Button für Config-Drift + Stale-Chunk-Auto-Reload — v1.2.86

Cluster/Replication:
- Drift-Banner: Button 'Resync erzwingen' baut die PG-Logical-Replication-
  Subscription neu auf (via edgeguard-ctl cluster-setup-standby).
- Primary-Dispatch: Button auf dem Primary delegiert per mTLS an den
  Standby (POST /agent/cluster/repair-replication); auf dem Standby lokal.
- Status-Proxy Primary->Standby via Aggregator.FanOut; Erfolg = Job-success
  ODER drift_found wird false (--collect-Unit verschwindet nach Erfolg).
- Job als transiente systemd-Unit edgeguard-repair-replication.service
  (sudoers exact-match + festes Script wie upgrade.sh).
- Banner-Text korrigiert (keine 'Outbox').

Frontend-Stabilität:
- Stale-Chunk-Auto-Reload: Lazy-Import-Fehler nach Deploy ('Failed to fetch
  dynamically imported module') lösen einen einmaligen Reload aus (Loop-
  Schutz via sessionStorage) statt einer Fehlerseite. Globaler
  vite:preloadError-Listener + ErrorBoundary-Integration.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

management-ui/src/i18n/locales/de/common.json

@@ -654,7 +654,17 @@
     "tokenLabel": "Token",
     "caFingerprintLabel": "CA-Fingerabdruck",
     "driftBanner": "Config-Drift erkannt",
-    "driftBannerDesc": "Ein oder mehrere Peers haben einen anderen Config-Hash als dieser Node. Entweder stehen noch Änderungen in der Outbox, oder auf einem Peer wurde direkt in der DB editiert. Warte bis die Outbox leer ist oder starte Diagnostics.",
+    "driftBannerDesc": "Ein oder mehrere Peers haben einen anderen Config-Hash als dieser Node. Kurz nach einer Änderung ist das normal (die Replikation hinkt nach) und verschwindet von selbst. Bleibt der Drift bestehen, ist die Replikation gestört oder es wurde direkt in die DB eines Peers geschrieben.",
+    "repair": {
+      "button": "Resync erzwingen",
+      "noStandbyHint": "Kein Standby-Node gefunden, an den der Resync delegiert werden könnte.",
+      "confirmTitle": "Replikation reparieren?",
+      "confirmDesc": "Baut die Replikations-Subscription auf dem Standby-Node neu auf und kopiert alle geteilten Config-Tabellen frisch vom Primary. Vom Primary aus geklickt wird der Resync per mTLS an den Standby delegiert. Lokale Direkt-Edits am Standby werden dabei überschrieben (Primary = Source of Truth).",
+      "confirmOk": "Resync starten",
+      "started": "Resync angestoßen — läuft im Hintergrund auf dem Standby.",
+      "ok": "Replikation repariert — Config wieder synchron.",
+      "failed": "Resync fehlgeschlagen"
+    },
     "col": {
       "node": "Knoten",
       "status": "Status",