docs: Schritt 3 ist im Spiel gelaufen -- der Durchstich steht

/studio shot adder, und das Bild lag Sekunden spaeter unter
https://fivemanage.d4rkst3r.de/f/vehicles/adder.webp. Von der Dienstseite
gegengeprueft statt der Logzeile geglaubt: 132908 Bytes hier wie dort,
derselbe SHA-256, ausgeliefert als image/webp, erste Bytes RIFF....WEBP --
ein echtes WebP und kein falsch benanntes PNG.

Damit ist die letzte Frage aus dem Pruefstand beantwortet: PerformHttpRequest
verhaelt sich in FiveM wie die Faelschung, Kopfzeilen und base64-Rumpf kommen
unveraendert an, der Rueckruf erreicht den Event-Handler.

Als ungeprueft benannt bleibt, was ungeprueft ist: ein ganzer Serienlauf ueber
900 Fahrzeuge, und Upload.put -- die wartende Form, die der Lauf nicht nimmt.

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

ROADMAP.md

@@ -284,10 +284,34 @@ Durchgemessen über die öffentliche Adresse, nicht über localhost:
 > binnen Millisekunden ist immer ein *Connection refused*, und dann stimmt eine
 > Portnummer nicht.
 
-### ⬜ Als Nächstes
+### ✅ Fertig — Schritt 3, der Fotostudio lädt selbst hoch
 
-**3 · `server/upload.lua` im Fotostudio — geschrieben, im Spiel noch nicht
-gelaufen.** Liegt in `d4rk_photostudio` (eigenes Repo, `D:\FXServer\txData\…`):
+**Am 11.08.2026 im Spiel gelaufen.** `/studio shot adder`, und die Konsole sagte
+in zwei Zeilen, was passiert ist:
+
+```
+[photostudio] Upload nach https://fivemanage.d4rkst3r.de — Dienst antwortet.
+[photostudio] adder freigestellt abgelegt (129 KB)
+[photostudio] adder hochgeladen: https://fivemanage.d4rkst3r.de/f/vehicles/adder.webp
+```
+
+Von der Dienstseite gegengeprüft, statt der Logzeile zu glauben: 132 908 Bytes
+hier wie dort, **derselbe SHA-256** (`f14dfc5b…5515e`), ausgeliefert als
+`image/webp`, und die ersten Bytes sind `RIFF….WEBP` — ein echtes WebP und
+kein falsch benanntes PNG.
+
+Damit ist auch die letzte offene Frage aus dem Prüfstand beantwortet:
+`PerformHttpRequest` verhält sich in FiveM wie die Fälschung, Kopfzeilen und
+base64-Rumpf kommen unverändert an, und der Rückruf erreicht den
+Event-Handler.
+
+**Was noch niemand gemessen hat:** ein ganzer Serienlauf über 900 Fahrzeuge —
+also 900 Uploads hintereinander, mit dem, was dabei an Fristen und
+Gleichzeitigkeit auftreten kann. Und `Upload.put`, die wartende Form, ist
+ungenutzt: der Lauf nimmt `Upload.send`. Sie steht da, weil die ROADMAP sie so
+benannt hat, und ist damit ungeprüfter Code.
+
+Der Quelltext liegt in `d4rk_photostudio` (eigenes Repo, `D:\FXServer\txData\…`):
 
 ```
 server/upload.lua              Upload.send(pfad, bytes, cb)  und  Upload.put(pfad, bytes) → url
@@ -309,21 +333,12 @@ einer nackten Zahl; Status 0; und dass die Frist den Rückruf nicht ein zweites
 Mal auslöst. Der Rumpf, den die VM erzeugt hat, ging danach **unverändert an
 den echten Dienst** — hochgeladen, abgerufen, Byte für Byte identisch.
 
-**Was offen bleibt, bis es einmal im Spiel lief:** ob `PerformHttpRequest`,
-`SetTimeout` und `promise` sich in FiveM so verhalten wie die Fälschungen, und
-ob der Event-Handler den Rückruf sauber erreicht. Dafür fehlt genau ein
-Handgriff, und er braucht die Serverkonsole:
+**Damit ist erreicht, worum es ursprünglich ging.** Ein Bild entsteht im Spiel,
+wird freigestellt, landet auf der Platte und liegt Sekunden später unter einer
+vorhersagbaren Adresse — ohne Fivemanage, ohne PostgreSQL, ohne MinIO, ohne
+einen einzigen Handgriff von Hand dazwischen.
 
-```
-refresh
-ensure d4rk_photostudio       (bzw. restart d4rk_photostudio)
-```
-
-Beim Start sagt die Resource in einer Zeile, ob der Dienst antwortet. Danach
-`/studio shot <modell>` im Spiel — das Bild muss unter
-`https://fivemanage.d4rkst3r.de/f/vehicles/<modell>.webp` stehen.
-
-Nach diesem Schritt ist das erreicht, worum es ursprünglich ging.
+### ⬜ Als Nächstes
 
 **4 · Dashboard.** React 18, TypeScript, Vite 5, Tailwind 4 (CSS-first),
 Lucide, Zustand. **Kein Konsta** — das ist für die Handy-Oberfläche richtig,