DOC-01: upload-api & chunk-handling

Fortsetzbarer Server-seitiger Upload: upload_sessions (bytes_received,
GREATEST-Update verhindert Rueckschritt bei erneut zugestellten Chunks),
Staging via os.File.WriteAt (beliebige Chunk-Reihenfolge/-Wiederholung),
MIME-/Groessen-Validierung vor jedem Byte. Complete() liest Klartext einmal
via io.TeeReader fuer SHA-256 UND Verschluesselung gleichzeitig (Reihenfolge
Hash->verschluesseln->ablegen eingehalten), legt Dokument+Revision
transaktional an (neue Spalte file_revisions.wrapped_dek fuer FDN-09).

Auf 192.168.1.131 verifiziert: Resume nach simuliertem Abbruch bei 50%
liefert identische Endpruefsumme, 20 parallele Uploads ohne Kollision/
Datenverlust, Pruefsumme entspricht exakt dem Klartext, transaktionale
Dokument+Revision-Anlage bestaetigt.

Reale Skalierungs-Einschraenkung gefunden: echter 1-GiB-Durchlauf endete
mit OOM (4GB-RAM-Testhost ohne Swap, FDN-03/FDN-09 puffern vollstaendig im
Speicher statt zu streamen). Auf 300 MiB reduziert vollstaendig verifiziert
(Upload/Verschluesselung/Ablage/Checksumme/Entschluesselungs-Round-Trip
alles exakt) - Ressourcen-, keine Korrektheitsfrage, dokumentiert als
Folgeticket-Kandidat statt stillschweigend uebergangen.

Siehe dms/docs/DOC-01-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ

dms/migrations/tenant/0003_upload_sessions.down.sql

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

dms/migrations/tenant/0003_upload_sessions.up.sql

@@ -0,0 +1,18 @@
+-- DOC-01: Sitzungszustand fuer fortsetzbaren Upload (Akzeptanzkriterium 1).
+-- Ein Sitzungseintrag je laufendem Upload, bytes_received wird bei jedem
+-- angenommenen Chunk aktualisiert — nach einem Verbindungsabbruch kann der
+-- Client anhand von bytes_received genau dort fortsetzen, wo er stand.
+CREATE TABLE upload_sessions (
+    id             UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    filename       TEXT NOT NULL,
+    mime_type      TEXT NOT NULL,
+    total_size     BIGINT NOT NULL CHECK (total_size > 0),
+    bytes_received BIGINT NOT NULL DEFAULT 0 CHECK (bytes_received >= 0),
+    folder_id      UUID REFERENCES folders(id) ON DELETE SET NULL,
+    created_by     UUID NOT NULL REFERENCES users(id),
+    status         TEXT NOT NULL DEFAULT 'uploading'
+                   CHECK (status IN ('uploading', 'completed', 'aborted')),
+    document_id    UUID REFERENCES documents(id),
+    created_at     TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at     TIMESTAMPTZ NOT NULL DEFAULT now()
+);

dms/migrations/tenant/0004_file_revisions_wrapped_dek.down.sql

@@ -0,0 +1 @@
+ALTER TABLE file_revisions DROP COLUMN IF EXISTS wrapped_dek;

dms/migrations/tenant/0004_file_revisions_wrapped_dek.up.sql

@@ -0,0 +1,6 @@
+-- DOC-01: file_revisions bekommt den verpackten Datenverschluesselungs-
+-- schluessel (DEK) aus FDN-09s Envelope-Encryption. Nullable, weil ein
+-- Datensatz theoretisch auch unverschluesselt vorliegen kann (z.B. der
+-- FDN-02-Entwicklungs-Seed) — DOC-01s regulaerer Upload-Pfad setzt ihn
+-- jedoch immer.
+ALTER TABLE file_revisions ADD COLUMN wrapped_dek BYTEA;