Pi-hole-Folge-Fixes: konfigurierbarer Top-Clients-count + Session-Invalidierung beim User-Löschen

[CallMeTechie]

Zwei unabhängige, dokumentierte Folge-Fixes der Initiative „Pi-hole im Portal" (TP1 #189 / TP2a #192 / TP2b #193). Ein PR, 6 Commits (nicht gesquasht).

Ticket A — konfigurierbarer Pi-hole-Top-Clients-Abruf

Die pro-Gerät- (TP2a) und pro-Besitzer-Aggregation (TP2b) summierten nur die Pi-hole-Top-Clients. Pi-hole liefert per Default Top-10 und der Sync cappte zusätzlich auf 10 → Geräte jenseits Platz 10 erschienen als no_data. Neu: konfigurierbarer Abruf-Umfang top_clients_count (Default 1000) macht die Attribution vollständig.

• getTopClients(blocked, count) hängt count nur an, wenn Number.isInteger(count) && count > 0 (back-compat ohne count).
• piholeConfig.DEFAULT.top_clients_count = 1000; PUT /settings/pihole clampt Math.max(1, Math.min(5000, parseInt(...) || 1000)).
• Sync threadet count explizit durch pull(client, count) (kein Closure/shared state); .catch(() => []) auf dem blocked-Call erhalten. Beide Client-Listen cappen mit count, topDomains bleibt Top-10.
• Admin-Monitoring-Karte GET /pihole/top-clients cappt die Anzeige auf 10 (.slice(0,10) nach scopeFilter); cache.topClients bleibt voll für die portal.js-Attribution.
• UI-Feld #pihole-top-clients-count in allen 3 Themes (aurora/default/pro) + settings.js (populate/save/autosave) + i18n en+de.

Ticket B — Session-Invalidierung beim User-Löschen

users.remove löschte den User + nullte den Peer-Besitz, invalidierte aber nicht dessen Sessions (gelöschte Person behielt bis ~24h TTL eine lebende Session). Neu: DELETE /users/:id ruft nach users.remove(id) route-level guarded req.sessionStore.destroyByUserId(id) (außerhalb der Transaktion, kein exceptSid). users.remove bleibt reiner DB-Service.

Tests

10 neue Tests + 75 Regression lokal grün (NODE_ENV=test, --test-force-exit), inkl. pihole_sync_v5_degrade/v6 (.catch-/URL-Erhaltung). Finaler Whole-Branch-Review: ready to merge, 0 Critical/Important.

Backlog (kein Security-Gap)

Verwaiste api_tokens-Rows beim User-Löschen werden nicht bereinigt — users.isEnabled blockt Token-Auth gelöschter User implizit. Cleanup = separates Folgeticket.