Close the last three restore-gate gaps, and make the gate test the real gate

Three defects that all shared a shape: the restore path looked checked and was
not.

An unreadable data revision was treated as a legacy set. backup.sh discards the
mysql error when reading alembic_version, so a set could be written with an
empty datarev; the compatibility check then fell through to the code-to-code
head comparison - the very check datarev was introduced to replace - and badged
the set restorable on no evidence at all. A manifest that CARRIES the key and
left it empty is now refused, while one with no key at all is still the genuine
legacy case and keeps the fallback. backup.sh records the failure in run history
rather than passing it over in a log line, since the set it just wrote cannot be
restored.

Dumps were bound to the schema they came from. mysqldump --databases bakes
CREATE DATABASE and USE <name> into the file, so restoring onto a site whose
MYSQL_DATABASE differs loaded every row into the dump's schema, left the live
database untouched, and reported success. New sets are dumped without it and
load into the schema named at restore time. Existing sets are still bound, so
the gate reads which schema they name and refuses a mismatch instead of
restoring beside the live data. Also dropped --no-tablespaces into the main
dump: it needs the PROCESS privilege the app user does not have on MySQL 8.

The gate's own test carried a copy of the gate. test-restore-datarev.sh
re-implemented the predicate in its own shell functions, so it would have stayed
green through any drift in restore.sh - including the plugin-chain hole fixed in
the previous commit, which it could never have caught. restore.sh now takes
RESTORE_CHECK_ONLY, which stops it immediately after the gates having touched
nothing, plus overridable paths for the migration and plugin trees. The test
drives the shipped script and asserts on its exit code, so the verdict under
test IS the verdict that ships. Confirmed non-vacuous by planting a violation:
disabling the plugin revision check turns the suite red.

Nine cases now, up from five, covering both plugin-chain directions, a plugin
the build does not have, and the schema binding.

Moving the schema check earlier was prompted by that test: it had been placed
after the safety copy, so it needed a live database to reach a verdict it can
reach for free. It sits with the other gates now and stops before anything is
written.

Round-tripped against a real stack after the dump format change: backup, mutate,
restore, data back to backup-time state, and the new dumps confirmed to carry no
schema name.

Suite 2607 passed / 9 skipped.

Scope: product

scripts/backup/backup.sh

@@ -47,6 +47,12 @@ mkdir -p "${SETDIR}"
 status_write backup database "${SETNAME}" "Dumping database"
 
 # 1. Database: whole-DB logical dump, consistent and non-blocking on InnoDB.
+# Dumped WITHOUT --databases on purpose. That flag bakes CREATE DATABASE and USE
+# <name> into the file, which pins the dump to the schema name it was taken
+# from: restoring onto a site whose MYSQL_DATABASE differs loaded the rows into
+# the dump's schema, left the live one untouched, and reported success.
+# --no-tablespaces because dumping tablespace metadata needs the PROCESS
+# privilege, which the app user does not have on MySQL 8.
 log "dumping database ${MYSQL_DATABASE} from ${MYSQL_HOST}"
 mysqldump \
 	--host="${MYSQL_HOST}" \
@@ -55,7 +61,8 @@ mysqldump \
 	--single-transaction \
 	--routines \
 	--triggers \
-	--databases "${MYSQL_DATABASE}" \
+	--no-tablespaces \
+	"${MYSQL_DATABASE}" \
 	| gzip -c > "${SETDIR}/db.sql.gz"
 log "database dump written ($(du -h "${SETDIR}/db.sql.gz" | cut -f1))"
 
@@ -73,7 +80,15 @@ DATAREV="$(mysql \
 	--skip-column-names --batch \
 	-e "SELECT version_num FROM alembic_version LIMIT 1;" \
 	"${MYSQL_DATABASE}" 2>/dev/null | tr -d '\r')"
-[ -n "${DATAREV}" ] || log "WARN could not read alembic_version - datarev will be empty"
+if [ -z "${DATAREV}" ]; then
+	# Recorded loudly rather than shrugged off: a set with no data revision
+	# cannot be gated on restore, and the gate treats an empty stamp as "no
+	# evidence" and refuses it. Better a visible warning now than a set that
+	# looks restorable and is not.
+	log "WARN could not read alembic_version - this set will NOT be restorable"
+	history_append backup warning "${SETNAME}" \
+		"Could not read alembic_version; set has no data revision and cannot be restored"
+fi
 
 # The same question for every PLUGIN chain. Each plugin owns an
 # alembic_version_<plugin> table, and those move independently of the core one: