Deploy and schema updates for testing

deploy.sh

@@ -48,6 +48,37 @@
 #
 # Override the location for a staging box with:  WEBROOT=/var/www/ss-staging ./deploy.sh
 #
+# --- the database account ------------------------------------------------
+#
+# The API connects as a least-privilege account with DML rights only. This is
+# deliberate: the server fetches untrusted URLs for link previews, and a
+# service able to reshape or drop its own tables is a far larger blast radius
+# than that feature warrants.
+#
+#   CREATE USER 'app'@'localhost' IDENTIFIED BY '<password>';
+#   GRANT SELECT, INSERT, UPDATE, DELETE ON application.* TO 'app'@'localhost';
+#   FLUSH PRIVILEGES;
+#
+#   -- deliberately NOT granted: CREATE, ALTER, DROP, INDEX
+#
+# Then set DB_USER=app and DB_PASS=<password> in ~/.env. Note the asymmetry:
+# the admin scripts here (backupDatabase.sh, applyLastBackup.sh,
+# applyScrapeSchema.sh) still connect as root with $PROD_DB_PASS.
+#
+# DELETE is genuinely required -- the scraper drops shell attachment rows for
+# dead links and purges expired cache entries.
+#
+# --- schema changes ------------------------------------------------------
+#
+# Because the app holds no DDL, a deploy that introduces schema changes needs
+# one manual step, run once per environment as a database admin:
+#
+#   ./applyScrapeSchema.sh
+#
+# It is idempotent, so re-running is safe. The API verifies the schema and the
+# grants at boot; if either is missing it logs the remedy and serves normally
+# with link previews disabled.
+#
 
 set -euo pipefail