PHASE 1 RESULT — docmost (driveless, Postgres 16), demo-hp, controller v0.219.0

THE FIVE LEGS, in order, from the controller log (evidence 08). Every one ran; every one succeeded.

  13:58:24  POST /backup/offbox/reconstitute            (the endpoint the UI's button posts to)
  13:58:27  leg 1  safety dump written  -> pre-restore-20260822T135827Z-docmost-postgres.sql (135 624 B)
  13:58:2x  leg 2  DB service identified -> [docmost-postgres]
  13:58:28  leg 3a stack stopped
  13:58:28  leg 3b volumes replayed      -> docmost_docmost_postgres_data
  13:58:29                                  docmost_docmost_redis_data
  13:58:30                                  docmost_docmost_storage        = "Restored 3 Docker volume(s)"
  13:58:30  leg 4  DB service ONLY started -> docker compose up -d docmost-postgres   (0.4s)
  13:58:30  leg 5  ImportDump  docmost-postgres.sql -> docmost-postgres (postgres)
  13:58:32         "Imported DB dump ... " / "replayed 1 DB dump(s)"          (2 s)
  13:58:32  full StartStack
  13:58:56  reconstituted docmost from snapshot 239dd86c:
              0 file(s) placed, 1 DB dump(s) replayed,
              safety dump=pre-restore-20260822T135827Z-docmost-postgres.sql, skewed=false

  Total 32 s. All three containers healthy afterwards.

WHAT CAME BACK
  pages before destruction : 3
  pages after destruction  : 0   (count(*) FROM pages = 0 — not even soft-deleted rows)
  pages after restore      : 3   same ids, same titles
  discriminator before     : ORIGINAL-VALUE-A
  discriminator moved to   : DESTROYED-VALUE-C   (deliberately, so a revert would be visible)
  discriminator after      : ORIGINAL-VALUE-A    -> the snapshot's value was restored

  Read back through the APP'S OWN interface after the restore: login HTTP 200, /api/pages/recent
  returned all 3 pages, and the body of the third still contained its GAMMA sentinel.

HYPOTHESES — what fired and what did not
  H1 (schema collision, dump replays over a restored data directory) — DID NOT FIRE.
     The import completed in 2 s with no error under ON_ERROR_STOP=1. This is the notable result:
     the two legs do not collide in practice for this app.
  H2 (replayed data directory will not start) — DID NOT FIRE. docmost-postgres came up healthy
     on a data directory that had just been replaced wholesale from a tar.
  H4 (credentials) — DID NOT FIRE. ImportDump discovered dbUser=docmost/dbName=docmost from the
     LIVE container and they matched the restored directory, as predicted: secrets are not
     regenerated on reconstitution.
  H3 (MariaDB vs Postgres error handling) — not applicable to this phase; Phase 4.

A FLAW IN THIS DRILL'S OWN PLANTING, recorded rather than hidden
  The first accented title was planted through a shell argument chain that double-escaped it, so
  it was stored as the LITERAL ASCII text Árvízt... rather than as accented bytes.
  Caught by reading the stored value back as hex. The pages round-tripped exactly, so Phase 1's
  Q1 answer stands — but the ACCENTED-BYTES coverage did not, and was re-measured in Phase 1b
  with the title embedded in a python source file inside the guest, never passed as a shell
  argument. Wire bytes and stored bytes were compared and are identical.

PHASE 1b — the accented round-trip, re-measured properly
  planted (wire bytes) : c3817276c3ad7a74c5b172c5912074c3bc6bc3b67266c3ba72c3b367c3a970203220e28094205233353662
  stored at plant time : identical
  destroyed            : all 4 pages permanently; count(*) FROM pages = 0
  restored (snapshot a49de51d, 14:05:33): 4 pages back
  accented title after : c3817276c3ad7a74c5b172c5912074c3bc6bc3b67266c3ba72c3b367c3a970203220e28094205233353662
  MATCH                : TRUE  ("Árvíztűrő tükörfúrógép 2 — R356b")
  discriminator        : DESTROYED-VALUE-C2 -> ORIGINAL-VALUE-A

  The first three pages also came back; page 01a029ad-8314-... still carries the double-escaped
  ASCII title, which is what this drill's own faulty plant stored. It is left in place as the
  record of that flaw rather than quietly re-planted.
