papra: mount the volume where the app actually writes (R-156, last leg)

papra mounted papra_data:/app/data while the application writes to
/app/app-data, so its database sat in the container's writable layer: lost on
redeploy, and tarred nightly as an empty directory while the healthcheck stayed
green. Last of the three apps R-156 convicted.

Decided from the IMAGE, not the README. docker inspect of
ghcr.io/papra-hq/papra:26.6.1-rootless gives WORKDIR=/app and all three data
paths under ./app-data (DATABASE_URL, DOCUMENT_STORAGE_FILESYSTEM_ROOT,
PAPRA_CONFIG_DIR) — and /app/data does not exist in the image at all.

Reconfiguring the app to write to /app/data was available and deliberately not
taken: it enumerates data paths, so a fourth added upstream would escape to the
writable layer again, silently — this defect re-armed. Mounting the app's own
data ROOT captures every current and future path by construction.

Precondition checked rather than inherited: docker ps -a (including stopped) on
BOTH demo guests, plus the hub fleet view (two enrolled hosts, zero papra) —
both boxes were wiped and rebuilt today, so the 2 August evidence was re-measured.

Proven by the runtime gate in both directions: CLEAN with the self-test passing,
and BROKEN when the mount is reverted, with the exact R-156 evidence. Full
catalog_gates.py papra: all three gates OK.

templates/papra/docker-compose.yml

@@ -16,7 +16,21 @@ services:
       - APP_BASE_URL=https://${SUBDOMAIN}.${DOMAIN}
       - AUTH_SECRET=${AUTH_SECRET}
     volumes:
-      - papra_data:/app/data
+      # R-156: a csatolási pont /app/app-data, NEM /app/data. A képfájl WORKDIR-je
+      # /app, és MINDHÁROM adatútvonal az ./app-data alá mutat (a képfájlból
+      # kiolvasva, nem a README-ből): DATABASE_URL=file:./app-data/db/db.sqlite,
+      # DOCUMENT_STORAGE_FILESYSTEM_ROOT=./app-data/documents, PAPRA_CONFIG_DIR=./app-data.
+      # A /app/data könyvtár a képfájlban nem is létezik — a régi csatolás olyan
+      # útvonalra mutatott, ahová az alkalmazás soha nem írt, így a db.sqlite a
+      # konténer írható rétegében maradt: újratelepítéskor elveszett, a napi mentés
+      # pedig üres könyvtárat tarolt, miközben a healthcheck végig zöld volt.
+      #
+      # Az alkalmazás adatútvonalainak átállítása (/app/data-ra) is járható lett
+      # volna, de az HÁROM környezeti változó karbantartását jelentené: ha a
+      # felsőbb projekt egy negyedik adatútvonalat vezet be, az megint csendben az
+      # írható rétegbe szökne. A gyökér csatolása minden jelenlegi ÉS jövőbeli
+      # adatútvonalat elkap. Ellenőrzi: scripts/check-volume-persistence.py.
+      - papra_data:/app/app-data
     networks:
       - traefik-public
     deploy: