feat: use host bind mounts for persistent data

docs/deployment.md

@@ -12,6 +12,19 @@ docker compose --profile tools run --rm wp-cli /scripts/bootstrap.sh
 NGINX binds to loopback ports 8080/8443. WordPress and MariaDB remain private. The
 bootstrap is safe to rerun and does not duplicate demo records.
 
+The default persistent paths are host-based bind mounts under `./runtime`. Before the
+first start, run:
+
+```bash
+./scripts/prepare-host-volumes.sh
+```
+
+The script reads `.env`, creates the configured paths, and applies the expected
+container ownership. For Linux hosts this avoids the common problem where Docker
+creates missing bind-mount directories as `root:root` and WordPress or MariaDB later
+cannot write to them. If a platform uses different image UIDs/GIDs, override
+`MARIADB_VOLUME_UID/GID`, `WORDPRESS_VOLUME_UID/GID`, or `CERTBOT_VOLUME_UID/GID`.
+
 ## Production
 
 Required controls:
@@ -35,7 +48,8 @@ behavior, removing only the staging certificate volume when necessary.
 
 ## State and rollback
 
-Database and WordPress file volumes must be backed up together. Code rollback is a
-container rebuild from a prior commit and does not require deleting volumes. Never use
-`docker compose down --volumes` where content must survive. Test database restoration
-in a disposable environment before any production restore.
+Database and WordPress file directories must be backed up together. Code rollback is a
+container rebuild from a prior commit and does not require deleting host data
+directories. Never delete the paths configured by `DB_DATA_PATH`, `WORDPRESS_DATA_PATH`,
+or `LETSENCRYPT_DATA_PATH` where content/certificates must survive. Test database
+restoration in a disposable environment before any production restore.