Phase 7b.1: upsert_runtime_printer schlägt fehl bei Upgrade von bestehender DB (UNIQUE name)

[strausmann]

Symptom

Beim Deploy von Phase 7b (#75 / commit 784decc) auf hhdocker02 läuft das Backend in eine Crash-Loop mit:

sqlite3.IntegrityError: UNIQUE constraint failed: printers.name
INSERT INTO printers (id, name, model, backend, connection, enabled, created_at, updated_at)
VALUES ('c497ec0797585d7096b5f0cac97b71f7', 'PT-P750W (172.16.50.212)', ...)

Ursache

upsert_runtime_printer in backend/app/db/lifespan.py keyt aktuell NUR auf Printer.id (die neue deterministische UUIDv5 aus C1). Wenn die DB bereits einen Printer-Row aus Phase 7a hat — mit einer ANDEREN id aber demselben name (PT-P750W (<host>)) — wird der existing-Lookup nicht gefunden und session.add(...) löst den UNIQUE-Constraint-Violation aus.

Test-Lücke

Alle 4 C2-Tests in tests/integration/db/test_lifespan_printer_upsert.py nutzen async_session_empty — kein Test deckt den "Upgrade-Pfad: bestehende DB mit altem Printer-Row" ab.

Hot-Fix Production

DB auf hhdocker02 komplett gelöscht (Nutzer-Freigabe: noch nichts live in Verwendung). Lifespan legt frisch an mit deterministischer UUIDv5.

Permanenter Fix-Vorschlag

Option A: upsert_runtime_printer macht zusätzlichen lookup nach name und DELETE+INSERT bei collision.
Option B: UniqueConstraint auf Printer.name entfernen (Alembic-Migration nötig).

Akzeptanzkriterien

• Neuer Test test_upsert_handles_existing_row_with_same_name_different_id in tests/integration/db/test_lifespan_printer_upsert.py
• Production-Deploy von Phase-7a-DB (nicht leer) führt nicht zum Crash
• Falls Option B: Alembic-Migration für drop_index

Refs #22