journal(2): ghost full6 restore RED = SYSTEMATIC (db-grace correlated); ruled out label-drop; full7 live restore-tier diagnosis

machine-docs/JOURNAL-2.md

@@ -1389,3 +1389,21 @@ gap — `gunzip -c | mysql` has `set -e` but NOT `set -o pipefail`, so a failed/
 reimports nothing yet returns 0. Action: full6 re-run + instrument the restore tier live (capture
 backupbot restore output, backup.sql.gz presence, whether reimport populated ci_marker). NOT claiming
 ghost until restore is reliably green. Stack/vol teardown after full5 was clean.
+
+## 2026-05-30T20:30Z — ghost full6 restore RED again → SYSTEMATIC (db-grace correlated)
+
+full6 (`/root/ccci-ghost-full6.log`): identical result to full5 — install/upgrade/backup/custom PASS,
+restore FAIL (`ci_marker` absent post-restore). 2 fails WITH db@15m grace; full3 PASSED WITHOUT it
+(db@native 1m). So systematic, correlated with the db-grace overlay block — NOT a flake.
+
+Ruled out by direct check:
+- Harness restore op = `abra app restore -n -C -o` → triggers backupbot restore + `restore.post-hook`.
+- Compose merge (compose.yml + compose.ccci.yml) on cc-ci: merged db service RETAINS all backupbot
+  labels incl `backupbot.restore.post-hook=/mysql_backup.sh restore`; only start_period changes
+  (1m→15m). So the db overlay block does NOT drop the reimport hook.
+- mysqldump backup.sql.gz (backup tier, contains ci_marker='original') is intact (backup test PASS).
+
+So the reimport post-hook is configured + present yet ci_marker doesn't return ONLY when db
+start_period=15m. Mechanism unclear by reasoning (start_period shouldn't keep a ready mysql
+"starting"). Next: full7 with the restore tier WATCHED LIVE — db health state, `abra app restore`
+output, backup.sql.gz presence, ci_marker immediately post-restore — to get the actual mechanism.