test(loadtest): an event simulation on a real 2 vCPU / 4 GB / 30 GB box

`driver.mjs` is a pipeline benchmark: synthetic images, uniform load, rate limits
off, and — the part that mattered — an unconstrained host, so the 1 GB app cap
was never exercised and the disk gate never fired. It could not have found
either of the two defects fixed in the preceding commits.

This harness differs in three ways that earn their keep:

REAL CONTENT. Uploads come from a pool of actual wedding photos and videos,
unedited, including the HEIC files and 25 MB frames the app is supposed to
REFUSE. Those refusals are the test, not noise to filter out — 152 of 932
attempts were refused, and the breakdown of WHY is the most actionable output.

PERSONAS. ~100 viewers and ~50 uploaders across nine behaviour profiles, six
device profiles, each with a join time and a session length. A casual guest who
posts four photos generates a completely different request mix than a
photographer dumping 130, and both differ from a kiosk holding one SSE stream all
night. A 37-case abuse suite covers malicious payloads, injection, cross-user
tampering, enumeration and the rate limiters.

RATE LIMITS STAY ON. `driver.mjs` disabled them because it ran every guest from
one IP. Almost every limit that matters is per USER, not per IP, and those are as
real for 150 synthetic sessions as for 150 phones — leaving them on is what lets
the abuse personas prove the defences work. The per-IP limits ARE distorted by
the single source address; that distortion is measured and reported rather than
configured away.

`docker-compose.sim.yml` reproduces the CX22 rather than asserting it: production's
per-service cpus/memory/cpu_shares verbatim, every container pinned to the SAME two
cores with `cpuset` so they genuinely contend, and a real loopback ext4 volume so
the app's own statvfs returns true numbers. Run the driver under `taskset` onto
other cores, or the load generator competes with the thing it measures.

`browser-check.mjs` covers what an HTTP driver structurally cannot: the SvelteKit
container, and whether the frontend ESCAPES the XSS caption the backend stores
verbatim. The backend stores captions raw by design, so the renderer is the entire
defence — and only a browser can prove the payload is inert. It reports
INCONCLUSIVE rather than PASS when the payload never reached the DOM, because a
check that renders nothing proves nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

e2e/docker-compose.sim.yml

@@ -0,0 +1,153 @@
+# EventSnap EVENT SIMULATION stack — models the real production box, not CI.
+#
+# Difference from docker-compose.test.yml (which is tuned for fast, unconstrained
+# Playwright runs): this file reproduces the CX22 the event actually runs on —
+#   * 2 vCPU total, shared by all four services
+#   * 4 GB RAM, split by the same per-service limits production ships
+#   * a REAL 30 GB filesystem for media + exports (loopback ext4), so statvfs
+#     inside the container returns true numbers and the disk gate / 507 path is
+#     exercised for real rather than simulated.
+#
+# Why cpuset on every service: production's per-service `cpus` ceilings sum to
+# 1.5 + 1.2 + 0.6 + 0.5 = 3.8 on a box that has 2. That oversubscription is the
+# point — the ceilings only bind when something else is competing, and cpu_shares
+# decides who wins. Reproducing that on a 12-core workstation requires confining
+# every container to the SAME two cores; without cpuset each service would get its
+# ceiling simultaneously and the contention under test would never happen.
+#
+# Bring up:   docker compose -f docker-compose.sim.yml up -d --build
+# Tear down:  docker compose -f docker-compose.sim.yml down -v
+#
+# The 30 GB volume is created out-of-band (see e2e/loadtest/sim-disk.sh) because a
+# loopback device must be attached by root; it is declared `external` here.
+
+x-cpuset: &cpuset '0,1'
+
+services:
+  db:
+    image: postgres:16-alpine
+    cpuset: *cpuset
+    environment:
+      POSTGRES_USER: eventsnap_test
+      POSTGRES_PASSWORD: eventsnap_test
+      POSTGRES_DB: eventsnap_test
+    healthcheck:
+      test: ['CMD-SHELL', 'pg_isready -U eventsnap_test -d eventsnap_test']
+      interval: 3s
+      timeout: 3s
+      retries: 30
+    ports:
+      - '55433:5432'
+    volumes:
+      # Named (not anonymous) so a `down -v` really wipes it and so its on-disk size
+      # can be measured against the 10 GB DISK_RESERVE that is meant to cover it.
+      - sim_pgdata:/var/lib/postgresql/data
+    # Production values, verbatim (docker-compose.yml db service).
+    deploy:
+      resources:
+        limits:
+          memory: 1G
+          cpus: '1.5'
+        reservations:
+          memory: 256M
+    cpu_shares: 2048
+    memswap_limit: 1152m
+
+  app:
+    # The SHIPPED release image, not a local build. Verified identical to HEAD:
+    # `git diff v0.17.5 HEAD -- backend/` is empty, and v0.17.5/v0.17.6 share one
+    # app digest on purpose (the v0.17.6 bump was frontend-only). Running the real
+    # artifact means the simulation tests what the event will actually run.
+    image: ${SIM_APP_IMAGE:-registry.mc02.dev/eventsnap/app:v0.17.5}
+    cpuset: *cpuset
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      DATABASE_URL: postgres://eventsnap_test:eventsnap_test@db:5432/eventsnap_test
+      JWT_SECRET: 00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff
+      # bcrypt("admin-test-pw"), cost 4. $ doubled to escape compose interpolation.
+      ADMIN_PASSWORD_HASH: $$2b$$04$$XKJJkNX6BOi6y3S42DA5JOWwk4oxc8DHPL6.MrPfJI2vpnccZjP32
+      EVENT_SLUG: sim-wedding
+      EVENT_NAME: Hochzeit Simulation
+      APP_PORT: '3000'
+      # Both live on the SAME 30 GB filesystem, as they do on the real VPS — but in
+      # sibling directories, because config.rs::validate requires EXPORT_PATH outside
+      # MEDIA_PATH (a keepsake archive contains every photo in the event).
+      MEDIA_PATH: /disk/media
+      EXPORT_PATH: /disk/exports
+      SESSION_EXPIRY_DAYS: '30'
+      # Production pins these; the CI stack leaves them at code defaults. Sized to 2 vCPU.
+      DATABASE_MAX_CONNECTIONS: '15'
+      COMPRESSION_WORKER_CONCURRENCY: '2'
+      # Production disables comments for this event (docker-compose.yml, product decision).
+      COMMENTS_ENABLED: 'false'
+      # The ONE deviation from production: enables /admin/__truncate so the harness can
+      # reset between runs. Never set on the real box.
+      EVENTSNAP_TEST_MODE: '1'
+      RUST_LOG: eventsnap_backend=info,tower_http=warn
+    volumes:
+      - sim_disk:/disk
+    deploy:
+      resources:
+        limits:
+          memory: 1G
+          cpus: '1.2'
+        reservations:
+          memory: 256M
+    cpu_shares: 512
+    memswap_limit: 1152m
+    expose:
+      - '3000'
+
+  frontend:
+    # Shipped release image; `git diff v0.17.6 HEAD -- frontend/` is empty.
+    image: registry.mc02.dev/eventsnap/frontend:v0.17.6
+    cpuset: *cpuset
+    depends_on:
+      - app
+    environment:
+      PORT: '3001'
+      HOST: '0.0.0.0'
+      ORIGIN: 'http://localhost:3102'
+    deploy:
+      resources:
+        limits:
+          memory: 256M
+          cpus: '0.6'
+    cpu_shares: 256
+    memswap_limit: 320m
+    expose:
+      - '3001'
+
+  caddy:
+    image: caddy:2-alpine
+    cpuset: *cpuset
+    depends_on:
+      - app
+      - frontend
+    volumes:
+      - ./Caddyfile.sim:/etc/caddy/Caddyfile:ro
+    deploy:
+      resources:
+        limits:
+          memory: 256M
+          cpus: '0.5'
+    cpu_shares: 1024
+    memswap_limit: 320m
+    ports:
+      - '3102:3102'
+
+volumes:
+  # 30 GB loopback ext4, created by e2e/loadtest/sim-disk.sh. Holds media AND exports,
+  # exactly as one VPS disk holds both.
+  sim_disk:
+    external: true
+    name: eventsnap_sim_media
+  # Postgres data stays on the host disk, NOT on the 30 GB volume. Scoping decision:
+  # the 30 GB budget under test is the one the APP manages and measures (statvfs on
+  # MEDIA_PATH drives the disk gate). Putting PG on the same volume would test
+  # filesystem exhaustion instead, and a full disk under Postgres risks ending the run
+  # for an infrastructural reason rather than an application one. Its growth is sampled
+  # separately and reported against DISK_RESERVE_BYTES (10 GB), which exists to cover it.
+  sim_pgdata: