IAM-01: benutzer-datenmodell-crud

Benutzer-Datenmodell + CRUD fuer Tenant-User (tenant-scoped, keine
tenant_id-Spalte noetig, Tenant ergibt sich aus der DB-Verbindung, Modell C)
und getrennt dafuer SuperadminStore fuer mandantenuebergreifende Konten in
der Registry-DB — First-Class-Typ statt tenant_id-NULL-Sonderfall im
Tenant-User-Code (bekannter archivdms-Fehler vermieden).

E-Mail-Eindeutigkeit: tenant-scoped fuer normale Benutzer (UNIQUE-Constraint
gilt nur innerhalb der jeweiligen Tenant-DB), global fuer Superadmins
(eine Registry-DB, ein UNIQUE-Constraint).

Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. CRUD automatisiert getestet inkl. Negativfaellen — TestTenantUserStore_CRUD
   deckt doppelte E-Mail (ErrEmailTaken) und unbekannte ID ab. PASS.
2. Superadmin-Anlage ohne Tenant-Kontext — TestSuperadminStore_CreateWithoutTenantContext:
   SuperadminStore.Create hat syntaktisch keinen Tenant-Parameter, kein
   if-Zweig fuer "kein Tenant" im Code. PASS.
3. Datenmodell von zweiter Person gegen Dokumentation geprueft — NICHT
   durchgefuehrt (keine zweite Person in dieser Session verfuegbar). Offen.

Tenant-User-Handler ist im Code vorhanden, aber in cmd/core/main.go noch
nicht geroutet — braucht Connection-Routing pro Mandant (TEN-06), das nicht
Teil dieser Kachel ist. Nur der Superadmin-Endpunkt ist verdrahtet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

migrations/0002_superadmins.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS superadmins;

migrations/0002_superadmins.up.sql

@@ -0,0 +1,14 @@
+-- Superadmin-Konten arbeiten mandantenuebergreifend und leben deshalb in der
+-- Control-Plane-Registry (siehe TEN-01), nicht in einer Tenant-Datenbank.
+-- Das bildet "Superadmin ohne Tenant" strukturell als First-Class-Zustand ab,
+-- statt ihn als Sonderfall in der Tenant-users-Tabelle zu behandeln
+-- (IAM-01, siehe core-kanban/tickets/IAM-01.md — bekannte Fehler vermeiden).
+-- E-Mail-Eindeutigkeit ist hier global, da die Registry-DB einmalig existiert.
+CREATE TABLE superadmins (
+    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    email        TEXT NOT NULL UNIQUE,
+    name         TEXT NOT NULL,
+    status       TEXT NOT NULL DEFAULT 'active',
+    created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at   TIMESTAMPTZ NOT NULL DEFAULT now()
+);

migrations/tenant/0001_users.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS users;

migrations/tenant/0001_users.up.sql

@@ -0,0 +1,16 @@
+-- Benutzer-Datenmodell (IAM-01, siehe core-kanban/tickets/IAM-01.md).
+-- Diese Migration laeuft in der DB EINES Mandanten (Modell C, siehe TEN-01) —
+-- die Tenant-Zugehoerigkeit ist implizit durch die Datenbankverbindung
+-- gegeben, es gibt daher bewusst KEINE tenant_id-Spalte.
+-- E-Mail-Eindeutigkeit ist hier tenant-scoped: der UNIQUE-Constraint gilt
+-- nur innerhalb dieser einen Tenant-Datenbank.
+CREATE EXTENSION IF NOT EXISTS pgcrypto;
+
+CREATE TABLE users (
+    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    email        TEXT NOT NULL UNIQUE,
+    name         TEXT NOT NULL,
+    status       TEXT NOT NULL DEFAULT 'active',
+    created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at   TIMESTAMPTZ NOT NULL DEFAULT now()
+);