Mediathek mit Ablagefläche, Updateverfahren geplant

Das Auswahlfeld des Browsers sah aus wie das Auswahlfeld des Browsers.
Hochgeladen wird jetzt über eine Ablagefläche: Bilder hineinziehen oder
klicken, darunter steht, welche Dateien gewählt sind und welche übersprungen
wurden.

Darunter liegt weiter ein echtes input[type=file] - unsichtbar, aber
fokussierbar, mit der Fläche als label und dem Fokusring über :focus-within.
Ohne JavaScript bleibt genau das übrig: ein Dateifeld mit Beschriftung. Das
Skript ergänzt Ziehen und benennt die Auswahl; abgeschickt wird nie von
selbst. Kein "required", weil der Browser seine Meldung nicht an etwas
Unsichtbares hängen kann - der Server weist einen leeren Upload mit einem
lesbaren Satz ab.

docs/UPDATE.md plant das Update über einen Git-Tag: Vorprüfung, Sicherung,
Wartungszustand mit 503 für die Website und offenem /admin, Checkout,
composer, Migration, Cache, Rauchtest, Protokoll - und den Rückweg in
derselben Reihenfolge rückwärts. Migrationen bleiben nicht umkehrbar, der
Rückweg ist die Sicherung. Kein Updater, der eine Adresse aus dem Formular
zieht, und kein automatisches Update im Hintergrund. Zwei Entscheidungen
hängen am Hosting: Composer auf dem Server oder vendor/ im Tag, und ob es
Shell-Zugriff gibt. Gebaut ist davon nichts.

219 PHP-Tests / 881 Assertions unter PHP 8.4.22, darunter Upload über das
Formular mit zwei Dateien, CSRF-Pflicht, Versionskonflikt, Archivfilter und
Blättern mit 26 Bildern. Playwright prüft die Ablagefläche am echten
Dateifeld; axe bleibt auf elf Bildschirmen ohne Verstöße.

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

docs/QUALITY.md

@@ -8,7 +8,9 @@
 - Acht abgewiesene Kontoanlagen erreichen die Datenbank nicht, darunter ein Passwort mit Nullbyte und eines mit 73 Bytes – letzteres, weil bcrypt alles über 72 Bytes stillschweigend ignoriert und ein längeres Passwort damit kürzer wäre, als es aussieht.
 - Die Migration lief mit Sicherung (`var/backups/before-users-*.db`) und erst als Probelauf gegen die Entwicklungsdatenbank: drei `ALTER TABLE ... ADD COLUMN`, kein Tabellenneubau.
 - **Dabei aufgefallen:** der lokale Vorschauserver lieferte 500 für die neuen Bildschirme, weil sein Prozess einen älteren kompilierten Container hielt – `cache:clear` ohne `--env=prod` räumt den nicht ab. Kein Codefehler, aber der Grund, warum eine Änderung im Browser gegen einen frisch gestarteten Server anzusehen ist.
-- **Nicht geprüft:** kein Screenreader; Upload und Blättern in der Mediathek sind mit zwei Bildern geprüft, nicht mit einer großen Bibliothek.
+- Mediathek über das Formular geprüft: zwei Dateien in einem Absenden, Upload ohne Token wird abgewiesen und legt nichts an, Bildangaben mit Versionskonflikt (zweites Speichern mit derselben Version ändert nichts und meldet es), Archivfilter, und Blättern mit 26 eingesetzten Bildern – 24 auf Seite eins, neueste zuerst, `?seite=99` wird auf die letzte Seite begrenzt, und Speichern von Seite zwei kommt auf Seite zwei zurück.
+- Die Ablagefläche ist zweimal geprüft: im Browsertest über das echte Dateifeld (die Auswahl erscheint im Feld und wird benannt) und von Hand mit einem echten Drop aus zwei Dateien, von denen die Nicht-Bilddatei übersprungen und gemeldet wurde. Ohne JavaScript bleibt ein gewöhnliches Dateifeld mit Beschriftung übrig; abgeschickt wird nie automatisch.
+- **Nicht geprüft:** kein Screenreader; die Mediathek ist mit 2 und mit 26 Einträgen geprüft, nicht mit einer wirklich großen Bibliothek. Vom Updateverfahren ist nichts geprüft, weil nichts gebaut ist – `docs/UPDATE.md` ist ein Plan.
 
 ## Ergänzung: Verwaltung neu gestaltet, 12.09.2026