fix(resume): persist uploads now that v5 stores them locally

Watchtower pulled the Reactive Resume rewrite (sha-3c195dc, built
2026-08-24) and recreated the container. The new build ignores the
STORAGE_*/MinIO vars and writes to LOCAL_STORAGE_PATH=/app/data, which
/api/health confirms ("storage": {"type": "local"}).

The app service had no volumes at all, so every avatar and export lived
in the container's writable layer and would vanish on the next recreate.
Bind /storage1/labdata/resume/data (pre-created 1000:1000, matching the
container's node user) to /app/data.

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

stacks/resume/docker-compose.yml

@@ -3,6 +3,7 @@
 # Volume -> bind-mount conversions (tiered per density policy):
 #   postgres data  -> /config/resume/postgres        (SSD; DB, low density)
 #   minio  data    -> /storage1/labdata/resume/minio (ZFS; object store, blobs)
+#   app uploads    -> /storage1/labdata/resume/data  (ZFS; blobs, see app below)
 # The Chrome service is stateless. app + resume-minio join edge (resume.ginnoir.com,
 # storage.j-costa.com, minio.ginnoir.com); postgres stays private.
 
@@ -75,6 +76,13 @@ services:
     networks: [resume, edge]
     ports:
       - "3000:3000"
+    volumes:
+      # The v5 rewrite stores uploads on the local filesystem
+      # (LOCAL_STORAGE_PATH=/app/data is baked into the image) and ignores the
+      # STORAGE_*/MinIO vars below — /api/health reports storage type "local".
+      # Without this bind, avatars and exports sit in the container's writable
+      # layer and are lost on every recreate, including Watchtower's.
+      - /storage1/labdata/resume/data:/app/data
     depends_on:
       postgres:
         condition: service_healthy