feat(peers): Geräte-Besitzer-Zuordnung (TP1 — peers.user_id + Admin-UI)

[CallMeTechie]

Teilprojekt 1 — Geräte-Besitzer-Zuordnung

Fundament der Initiative „Pi-hole im Portal": Geräte (Peers) können optional einem Besitzer (bestehendes users-Konto) zugeordnet werden. Reines Daten- + Admin-UI-Fundament — keine Portal-Optik, portalIdentity unangetastet.

Was drin ist

• Migration (V59): nullable Spalte peers.user_id + Index idx_peers_user_id (ohne inline-FK — SQLite ignoriert REFERENCES bei ADD COLUMN; FK-Semantik im Service-Layer).
• Service: peers.create schreibt+returnt user_id; peers.update setzt/löscht (undefined=unverändert, null=löschen, <n>=setzen).
• Owner-Cleanup: users.remove löst Besitz transaktional (UPDATE peers SET user_id=NULL vor DELETE) — Gerät überlebt besitzerlos.
• Admin-API: POST/PUT /api/v1/peers akzeptieren+validieren user_id (ungültig → 400); GET liefert user_id+owner_name (einmaliger Prefetch, kein N+1).
• Bulk: POST /api/v1/peers/batch-owner — kollisionsfrei VOR /:id registriert, erbt Admin-Auth+CSRF, Limit ≤ 500.
• UI (3 Themes): Owner-<select> in Add/Edit-Peer-Partials + Bulk-Zuweisung in der bestehenden Batch-Bar.
• i18n: en + de.

Sicherheit / Scope

• user_id/owner_name nur im Admin-Pfad — verhaltensbasierter Leak-Regressionstest (/api/v1/portal/device-Roundtrip + Quell-Scan über alle client/*-Routen + portal.js).
• src/middleware/portalIdentity.js nachweislich unverändert (Scope-Zusicherung). Kein req.portalOwnerId-Seam, keine Aggregations-Helfer, kein Pi-hole-Widget — alles TP2.
• Gateways unterstützen bewusst keinen Owner.
• Nur parametrisiertes SQL; DOM-sicheres Rendering; Community-Tier.

Tests

• TP1-Suite: 19 grün (tests/peer_owner_*.test.js).
• Regression: portal_identity* + peers* + users* = 32 grün; i18n-Parität 2 grün.

Schnittstelle zu TP2

Die persistierte peers.user_id-Spalte ist die einzige TP1→TP2-Schnittstelle.

Prozess

Subagent-driven (8 Tasks, TDD, zweistufiges Review je Task) + finales opus-Whole-Branch-Review: „Ready to merge".

🤖 Generated with Claude Code