fix(e12): a bare up -d picks the wrong compose file, and recreates the database

Round four, on round three's diff. 47 -> 34 -> 15 -> 7 raw findings.

**The printed restart command could strand the restored data.** Round three replaced
`start` with `up -d` because `start` ignores a newly pinned tag — but printed it bare. In
the git-clone layout BOTH compose files exist, so the scripts' COMPOSE_FILE fallback never
fires and a bare `docker compose up -d` reads `docker-compose.yml`: different volume names,
locally built images, no IMAGE_TAG at all. `stop` and `exec` had been fine there (they
resolve running containers by project and service), but `up -d` RECREATES — so the operator
pastes the hint straight after a successful restore and gets `db` on a new empty volume and
a first-run setup wizard, with their data in an orphaned volume. Verified: the two files
resolve `siftlode_pgdata` vs `pgdata` and different images.

The scripts no longer print a command that recreates from a file they did not resolve. They
name the compose file when they resolved one, and otherwise say to start it the way the
operator normally does — with the caveats on their own lines rather than in a parenthetical
at the end of a very long one.

**The reset flag is now decided where the live hash is already parsed.** Round three cleared
it in the token effect, which only runs when a NEW verify token arrives — so the back
button, or re-pasting an already-consumed verify link, still left the banner promising a
recovery whose token was gone. Setting it from the hash on every fragment change is both
smaller and closes those.

Also: the doc said `start` "still carries the old tag" four lines after "pin the older
IMAGE_TAG", where "old" then reads as the tag being rolled back TO — it now reuses the
scripts' unambiguous wording; the Windows recipe removes a partially-copied dump before
throwing, so a mid-stream `cp` failure cannot leave a truncated file under the final name;
and `$WarningPreference` is pinned beside `$ErrorActionPreference` so an inherited
SilentlyContinue cannot drop the half-restored warning, with the comment corrected to say
what the warning stream actually is.

Gate green: vitest 685, pytest 950.

scripts/restore.ps1

@@ -6,6 +6,7 @@
 # values and refresh tokens will not be readable. See docs/self-hosting.md § Backups.
 param([Parameter(Mandatory = $true)][string]$DumpFile)
 $ErrorActionPreference = "Stop"
+$WarningPreference = "Continue"
 
 # See backup.ps1: the dump travels with `docker compose cp`, never through the PowerShell pipeline,
 # which corrupts binary on 5.1 and cannot express `-Encoding Byte` at all on 7.
@@ -54,10 +55,18 @@ Remove-RemoteDump $remote
 # reports every missing object it tried to drop), so a non-zero code is reported as "check this",
 # not swallowed and not dressed up as success.
 if ($restoreCode -ne 0) {
-    # Write-Warning, not Write-Output: this must ride the same stream as the exception below, or a
-    # `> restore.log` redirection files the explanation away and leaves only the raw error on screen.
+    # Write-Warning, not Write-Output: `>` redirects only the SUCCESS stream, so on stdout this
+    # explanation would be filed into the log while the bare exception stayed on screen. (The
+    # warning stream is its own stream, not the error stream — $WarningPreference is pinned at the
+    # top so an inherited "SilentlyContinue" cannot drop it.)
     Write-Warning "api and worker are left STOPPED: the database may be half-restored. Fix the dump and re-run before starting them."
     throw "pg_restore reported errors while restoring $DumpFile (exit $restoreCode) — read the output above before treating this instance as restored."
 }
 Write-Output "Restored $DumpFile"
-Write-Output "api and worker are stopped. Start them with: docker compose up -d  (rolling a release back? pin the older IMAGE_TAG in .env FIRST — 'docker compose start' would relaunch the CURRENT image and re-apply its migrations)"
+$cf = if ($env:COMPOSE_FILE) { " -f $env:COMPOSE_FILE" } else { "" }
+Write-Output "api and worker are stopped. Start them again the way you normally start Siftlode:"
+Write-Output "  docker compose$cf up -d"
+Write-Output "Use the SAME compose file you started with — 'up -d' recreates from whatever file it reads,"
+Write-Output "and a different one points at different volumes. Rolling a release back? Pin the older"
+Write-Output "IMAGE_TAG in .env FIRST: every start re-runs the migrations, and 'start' would relaunch the"
+Write-Output "existing container on the image you are rolling back FROM."

scripts/restore.sh

@@ -42,7 +42,12 @@ fi
 # not swallowed and not dressed up as success.
 if docker compose exec -T db pg_restore -U "$USER_NAME" -d "$DB_NAME" --clean --if-exists < "$FILE"; then
   echo "Restored $FILE"
-  echo "api and worker are stopped. Start them with: docker compose up -d  (rolling a release back? pin the older IMAGE_TAG in .env FIRST — 'docker compose start' would relaunch the CURRENT image and re-apply its migrations)"
+  echo "api and worker are stopped. Start them again the way you normally start Siftlode:"
+  echo "  docker compose ${COMPOSE_FILE:+-f $COMPOSE_FILE }up -d"
+  echo "Use the SAME compose file you started with — 'up -d' recreates from whatever file it reads,"
+  echo "and a different one points at different volumes. Rolling a release back? Pin the older"
+  echo "IMAGE_TAG in .env FIRST: every start re-runs the migrations, and 'start' would relaunch the"
+  echo "existing container on the image you are rolling back FROM."
 else
   echo "pg_restore reported errors while restoring $FILE — read the output above before treating this instance as restored." >&2
   echo "api and worker are left STOPPED: the database may be half-restored. Fix the dump and re-run before starting them." >&2