feat: Papierkorb, Abrufzaehler, WebP ohne Adressaenderung, ZIP hochladen

Vier Dinge, alle am laufenden Dienst gemessen.

PAPIERKORB. Loeschen war endgueltig -- bei einem Knopf "alle 3861 waehlen"
direkt neben "loeschen" ist das die falsche Haerte, und die Sicherung half nur
bis zum letzten naechtlichen Lauf. Die Datei wandert jetzt nach
/data/papierkorb, der Datensatz in eine eigene Tabelle, nach 30 Tagen raeumt
der Dienst stuendlich selbst auf. Der Ablagename traegt eine laufende Nummer:
unter demselben Pfad koennen nacheinander verschiedene Dateien gelegen haben,
und beide sollen zurueckholbar sein. Geprueft: loeschen -> oeffentlich 404,
Eintrag im Papierkorb, zurueckholen -> 200 samt neu gerechneter Vorschau.

ABRUFZAEHLER. media.abrufe und zuletzt_abgerufen. Gezaehlt wird im Speicher und
alle 30 Sekunden weggeschrieben -- ein UPDATE je Kachel waeren bei einer
Galerieseite 120 Schreibvorgaenge. Der 304 zaehlt mit (der Aufrufer WOLLTE die
Datei, er hatte sie nur schon), HEAD nicht. Was vor dem Einbau lag, steht als
"nie geholt" da, auch wenn es taeglich benutzt wurde -- die Karte im
Speicherbericht sagt das auch dazu, statt eine Zahl zu zeigen, die luegt.

WEBP OHNE ADRESSAENDERUNG. Der Pfad ist die Adresse: aus items/foo.png darf
nicht items/foo.webp werden. Die sparsame Fassung liegt deshalb DANEBEN und
wird unter DERSELBEN Adresse ausgeliefert, wenn der Aufrufer per Accept sagt,
dass er WebP versteht. Nachgemessen an einer Datei: 6448 Bytes fuer curl, 2758
fuer einen Browser. Ueber den ganzen Bestand: 3606 Fassungen, 199,3 MB ->
33,1 MB, gespart 166,2 MB. Bei 29 lohnt WebP nicht -- dort bleibt es beim
Original.

Zwei Dinge haengen daran, beide gegengeprueft: "Vary: Accept" (ohne die Zeile
legt ein Zwischenspeicher die WebP-Fassung fuer alle ab, auch fuer die, die sie
nicht lesen koennen) und getrennte ETags mit "-w" (sonst bekaeme jemand auf
seinen If-None-Match hin ein 304 fuer das falsche Bild). Gemessen: derselbe
ETag mit Accept -> 304, ohne Accept -> 200 mit dem PNG.

ZIP HOCHLADEN. Ein Archiv wird ausgepackt statt abgelegt, die Ordner darin
bleiben erhalten und haengen sich hinter den gewaehlten Zielordner. fflate und
nicht adm-zip: reines JavaScript, keine native Bibliothek -- dieses Projekt hat
schon einen halben Abend an einer ABI-Nummer verloren. Grenzen: 5000 Eintraege,
256 MB entpackt, geprueft VOR dem Entpacken (eine Zip-Bombe waere sonst schon
im Speicher). Zip-Slip gemessen: "../../../../etc/passwd" und
"..\..\windows\hosts" abgelehnt, die harmlose Datei im selben Archiv abgelegt.

UND EIN KNOPF, DER GELOGEN HAT. Der erste Nachruestlauf ueber alle Dateien
brauchte mehr als 90 Sekunden -- genau da gibt Nginx Proxy Manager auf. Der
Aufrufer sah einen 504, waehrend die Arbeit im Hintergrund weiterlief und
fertig wurde. Ein Knopf, der Erfolg als Fehler meldet, ist schlimmer als einer
ohne Rueckmeldung.

Beide Wartungsknoepfe laufen deshalb in Runden zu 300 Stueck: der Server meldet
"offen" und "fertig", die Oberflaeche ruft erneut auf und zeigt dabei "280
erzeugt, noch 129 offen ...". Gemessen: 7,8 s je Runde statt 90+ am Stueck. Der
Vorschau-Knopf hatte dieselbe Wand und wurde mitgezogen, obwohl er noch nicht
dagegengelaufen war.

Nebenbei: der Verwaisten-Sucher kennt jetzt auch /data/webp (gleiche Schleife,
Ordner im Ergebnis vorangestellt), Verschieben und Loeschen nehmen die sparsame
Fassung mit, und das Loeschen eines Ordners raeumt thumbs/ und webp/ hinterher.

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

server/src/db.ts

@@ -98,6 +98,29 @@ CREATE INDEX IF NOT EXISTS events_at ON events(at DESC);
 -- Port, Datenordner) bleibt in der Umgebung, damit ein falscher Klick den
 -- Dienst nicht unerreichbar macht. Hier liegt nur, was ohne Neustart
 -- verstellbar sein soll -- derzeit die Discord-Anmeldung.
+-- Der Papierkorb.
+--
+-- Loeschen war bis hierhin endgueltig: die Datei war von der Platte weg, und
+-- die Sicherung half nur bis zum letzten naechtlichen Lauf. Bei einem Knopf
+-- "alle 3670 waehlen" direkt neben "loeschen" ist das die falsche Haerte.
+--
+-- Die Datei wandert deshalb nach /data/papierkorb und der Datensatz hierher.
+-- Was hier steht, ist alles, was zum Zurueckholen noetig ist -- der Pfad ist
+-- der Schluessel, und den behalten wir.
+CREATE TABLE IF NOT EXISTS papierkorb (
+    id          INTEGER PRIMARY KEY,
+    path        TEXT    NOT NULL,
+    size        INTEGER NOT NULL,
+    sha256      TEXT    NOT NULL,
+    mime        TEXT    NOT NULL,
+    geloescht   INTEGER NOT NULL,
+    von         TEXT    NOT NULL,
+    -- Der Name IM Papierkorb. Nicht der Pfad: zwei Dateien koennen nacheinander
+    -- unter demselben Pfad gelegen haben, und beide sollen zurueckholbar sein.
+    ablage      TEXT    NOT NULL
+);
+CREATE INDEX IF NOT EXISTS papierkorb_zeit ON papierkorb(geloescht DESC);
+
 CREATE TABLE IF NOT EXISTS settings (
     key        TEXT    PRIMARY KEY,
     value      TEXT    NOT NULL,
@@ -141,6 +164,16 @@ CREATE TABLE IF NOT EXISTS settings (
         console.log('[db] Spalte events.von angelegt')
     }
 
+    // Abrufe. Die Frage "was braucht eigentlich noch jemand" laesst sich von
+    // innen nicht beantworten -- von aussen schon: wer wird geholt, wie oft,
+    // wann zuletzt. Das ist die Zahl, die dem Aufbewahrungsbericht fehlt.
+    const mSpalten = db.prepare('PRAGMA table_info(media)').all() as { name: string }[]
+    if (!mSpalten.some((s) => s.name === 'abrufe')) {
+        db.exec('ALTER TABLE media ADD COLUMN abrufe INTEGER NOT NULL DEFAULT 0')
+        db.exec('ALTER TABLE media ADD COLUMN zuletzt_abgerufen INTEGER')
+        console.log('[db] Spalten media.abrufe und zuletzt_abgerufen angelegt')
+    }
+
     if (!spalten.some((s) => s.name === 'discord_avatar')) {
         db.exec('ALTER TABLE users ADD COLUMN discord_avatar TEXT')
         db.exec('ALTER TABLE users ADD COLUMN discord_name TEXT')
@@ -236,6 +269,20 @@ export type Media = {
     token_id: number | null
     created_at: number
     updated_at: number
+    /** Wie oft die Datei oeffentlich geholt wurde. */
+    abrufe: number
+    zuletzt_abgerufen: number | null
+}
+
+export type PapierkorbEintrag = {
+    id: number
+    path: string
+    size: number
+    sha256: string
+    mime: string
+    geloescht: number
+    von: string
+    ablage: string
 }
 
 export type EventKind = 'upload' | 'replace' | 'delete' | 'move'
@@ -282,6 +329,44 @@ export function logEvent(
 /** Der Verlauf waechst mit jedem Upload. Bei 900 Fahrzeugen je Lauf sind das
  *  900 Zeilen -- kein Problem, aber auf Dauer auch kein Grund, alles zu
  *  behalten. Ein halbes Jahr reicht fuer die Frage "wer war das". */
+// -- Abrufe zaehlen, ohne die Auslieferung zu bremsen -------------------------
+//
+// Ein UPDATE je Bildabruf waere bei einer Galerieseite mit 120 Kacheln ein
+// Schreibvorgang je Kachel. Stattdessen wird im Speicher gezaehlt und
+// gelegentlich weggeschrieben -- wer wissen will, ob eine Datei benutzt wird,
+// braucht keine Genauigkeit auf die Sekunde.
+//
+// Was bei einem Absturz verlorengeht, sind hoechstens 30 Sekunden Zaehlerei.
+
+const offeneAbrufe = new Map<string, { anzahl: number; zuletzt: number }>()
+
+export function zaehleAbruf(path: string): void {
+    const bisher = offeneAbrufe.get(path)
+    if (bisher) {
+        bisher.anzahl++
+        bisher.zuletzt = now()
+    } else {
+        offeneAbrufe.set(path, { anzahl: 1, zuletzt: now() })
+    }
+}
+
+const abrufSchreiben = db.prepare(
+    'UPDATE media SET abrufe = abrufe + ?, zuletzt_abgerufen = ? WHERE path = ?',
+)
+
+export function schreibeAbrufe(): void {
+    if (offeneAbrufe.size === 0) return
+    const stapel = [...offeneAbrufe.entries()]
+    offeneAbrufe.clear()
+    try {
+        db.transaction(() => {
+            for (const [path, w] of stapel) abrufSchreiben.run(w.anzahl, w.zuletzt, path)
+        })()
+    } catch (err) {
+        console.error('[abrufe] konnten nicht geschrieben werden:', err)
+    }
+}
+
 export function pruneEvents(tage = 180) {
     db.prepare('DELETE FROM events WHERE at < ?').run(now() - tage * 86_400_000)
 }