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.

docs/self-hosting.md

@@ -196,7 +196,8 @@ docker compose -f docker-compose.selfhost.yml exec -T db \
 # Start it again only once the restore reported no errors — and, if you are rolling a release back,
 # only AFTER pinning the older IMAGE_TAG. Every start runs `alembic upgrade head`, so bringing the
 # newer image back here would re-apply the migrations you just restored away. Use `up -d`, not
-# `start`: `start` relaunches the container that already exists, which still carries the old tag.
+# `start`: `start` relaunches the existing container, so it ignores the tag you just pinned and
+# comes back on the image you are rolling back FROM.
 docker compose -f docker-compose.selfhost.yml up -d
 ```
 
@@ -224,7 +225,9 @@ copy would still run after a failed dump — and copy out the previous run's fil
   docker compose -f $compose cp db:/tmp/s.dump $out
   $code = $LASTEXITCODE
   docker compose -f $compose exec -T db rm -f /tmp/s.dump
-  if ($code -ne 0) { throw "BACKUP FAILED - could not copy the dump out (exit $code)" }
+  # Remove the partial file too: `cp` streams, so a mid-stream failure leaves a truncated dump
+  # under the final name — the plausible-looking bad backup the .part dance above avoids.
+  if ($code -ne 0) { Remove-Item $out -ErrorAction SilentlyContinue; throw "BACKUP FAILED - could not copy the dump out (exit $code)" }
   if ((Get-Item $out).Length -eq 0) { Remove-Item $out; throw "BACKUP FAILED - the dump came out empty" }
   "wrote $out"
 }