5 Varianten × 5 Runs. Konstanter upload.dek-Payload (96 Bytes). Einzige Variable: vorherige KMS-Sequenz. 10s Race, bei Timeout bis 65s Nachbeobachtung, LATE-SUCCESS-Cleanup.
A isoliert (V1/V2 ≈ 1,4 s) vs. B orchestriert (V5 >10 s) — bei identischem Payload und identischem hetznerUpload-Code. Der einzige Unterschied ist die Anzahl/Art der vorherigen Base44-Function-Aufrufe (KMS).
H1 — Sequenzlänge / Gateway-Serialisierung: Jede vorige Function belegt den Gateway-Pfad; ab einer bestimmten Anzahl wartet derfolgende hetznerUpload auf eine freie Gateway-Verbindung / einen Serialisierungs-Slot. → Effekt sollte mit der Anzahl der vorigen Calls monoton wachsen (V1<V2<V3<V4<V5).
H2 — Spezifische KMS-Operation (rewrap oder 2. wrap): Eine bestimmte Operation (rewrap, oder der zweite wrap) hinterlässt einen Zustand (Verbindung, Warm-Cache, Rate-Limiter), der den nachfolgenden Upload verlangsamt. → Effekt springt bei V4 oder V5, nicht gleitend.
H3 — Kumulierte Latenz ≠ Upload-Veränderung: Die vorigen KMS-Calls summieren sich; der „Timeout bei 10876 ms" ist die Gesamtdauer ab V0, nicht eine Verlangsamung des Upload selbst. → Dann wäre upload.dek selbst auch in V5 schnell, und der Trace zeigt response_done < 1000 ms trotz Gesamt > 10 s (Messung wird das zeigen).
Unterscheidung: H3 wird ausgeschlossen, wenn in V5 der gemessene upload.dek-Block selbst (fetch_start→response_done bzw. clientSettle) > 10 s braucht. Bleibt er schnell, ist es H3 (Kumulation). Ist er langsam und gleitet es mit der Sequenzlänge → H1. Springt es → H2. Ergänzend: tritt LATE SUCCESS auf (Upload wird nach 10 s doch mit HTTP 200 fertig), entsteht ein Orphan-Objekt — die Nachbeobachtung + Cleanup zeigt das.
Aktion: Matrix ausführen → kleinsten auslösenden Schnitt identifizieren → dann erst Fix.