IAM-02: login-session-jwt-grundgeruest

internal/auth: Login/Logout ueber httpOnly/Secure/SameSite=Strict-Cookie mit
HS256-JWT (30min TTL), bcrypt-Passwort-Hashing (Cost 12, explizit begruendet
und benchmarkt statt DefaultCost uebernommen), RequireAuth-Middleware fuer
geschuetzte Routen. LoginService ist strukturell auf einen Tenant gescopt
(nutzt user.TenantUserStore, dessen Pool = eine Tenant-DB — derselbe
Mechanismus wie in TEN-01/TEN-02), liefert bei falscher E-Mail und falschem
Passwort denselben Fehler (User-Enumeration-Schutz) inkl. Dummy-bcrypt-
Vergleich gegen Timing-Seitenkanal bei unbekannter E-Mail.

user.TenantUserStore erweitert um SetPasswordHash/GetByEmailForAuth
(password_hash bleibt ausserhalb des regulaeren User-Typs/JSON-Pfads).
Migration 0002 fuegt password_hash-Spalte hinzu (Default '', da IAM-01
User ohne Passwort anlegt).

Login-Handler ist wie IAM-01/TEN-02 aus denselben Gruenden (Tenant-
Connection-Routing = TEN-06, noch nicht gebaut) nicht in cmd/core/main.go
verdrahtet — Package ist eigenstaendig nutzbar/getestet.

Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Login-Query tenant-gescopt — TestLoginService_NoCrossTenantLogin: gleiche
   E-Mail in zwei Tenant-DBs mit unterschiedlichem Passwort, Login gegen
   Tenant A mit Tenant-B-Passwort schlaegt fehl. PASS.
2. Session-Fixation/Token-Manipulation — TestTokenVerify_RejectsManipulatedPayload
   und TestTokenVerify_RejectsWrongSecret: manipuliertes/falsch signiertes
   Token wird abgelehnt. PASS.
3. Abgelaufenes Token erzwingt Neuanmeldung — TestTokenVerify_RejectsExpiredToken
   und TestRequireAuth_BlocksWithoutValidCookie. PASS.
4. Login-Latenz mit Kostenfaktor 12 gemessen: 294ms (Ziel < 400ms) —
   TestBcryptCostAgainstLatencyTarget. PASS.

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

internal/auth/token.go

@@ -0,0 +1,63 @@
+package auth
+
+import (
+	"errors"
+	"time"
+
+	"github.com/golang-jwt/jwt/v5"
+)
+
+// AccessTokenTTL ist bewusst kurz gehalten (Session-Ablauf statt langlebiger
+// Tokens), passend zur "so vertrauenswuerdig wie noetig"-Produkt-DNA.
+const AccessTokenTTL = 30 * time.Minute
+
+var ErrInvalidToken = errors.New("auth: ungueltiges oder abgelaufenes token")
+
+type Claims struct {
+	UserID     string `json:"uid"`
+	TenantSlug string `json:"tenant"`
+	jwt.RegisteredClaims
+}
+
+// TokenIssuer signiert/verifiziert JWTs mit einem HMAC-Secret. Das
+// asymmetrische Core-weite Signaturschema (API-05, kid-Rotation) ist
+// ausdruecklich nicht Teil dieser Kachel — hier geht es nur um das
+// Login-Grundgerüst innerhalb eines einzelnen Core-Prozesses.
+type TokenIssuer struct {
+	secret []byte
+}
+
+func NewTokenIssuer(secret string) *TokenIssuer {
+	return &TokenIssuer{secret: []byte(secret)}
+}
+
+func (i *TokenIssuer) Issue(userID, tenantSlug string) (string, error) {
+	now := time.Now()
+	claims := Claims{
+		UserID:     userID,
+		TenantSlug: tenantSlug,
+		RegisteredClaims: jwt.RegisteredClaims{
+			IssuedAt:  jwt.NewNumericDate(now),
+			ExpiresAt: jwt.NewNumericDate(now.Add(AccessTokenTTL)),
+		},
+	}
+	token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
+	return token.SignedString(i.secret)
+}
+
+// Verify prueft Signatur UND Ablauf (jwt.ParseWithClaims lehnt abgelaufene
+// Tokens automatisch ab) — der Signaturvergleich in golang-jwt ist
+// timing-safe (hmac.Equal).
+func (i *TokenIssuer) Verify(tokenString string) (*Claims, error) {
+	claims := &Claims{}
+	token, err := jwt.ParseWithClaims(tokenString, claims, func(t *jwt.Token) (interface{}, error) {
+		if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
+			return nil, ErrInvalidToken
+		}
+		return i.secret, nil
+	})
+	if err != nil || !token.Valid {
+		return nil, ErrInvalidToken
+	}
+	return claims, nil
+}