Check the migration actually kept everything, and let report say so

internal/validate was written and tested and then never called: `run` ended
at cutover, so the tool performed a migration and never confirmed it had
carried the data across, and `report` was an error message pointing at the
package that would have answered.

`run` now compares the migrated instance against the snapshot preflight took
and fails if an account or a domain that existed before is missing from it.
The comparison runs against the service cutover has just started, which is
the instance people will actually use - its real config, its real ports,
under its real service manager - and costs no extra downtime; booting a
second copy inside the maintenance window would. BootCheck stays as the
equivalent for an instance the tool boots itself.

The service is left running on a failure. By that point the store has been
migrated in place, so stopping it undoes nothing, and only the operator can
weigh the finding against their recovery point.

A check that could not run is reported as skipped, never as a pass. Preflight
only captures the "before" when it has an admin URL, and a run without one
has to say it compared nothing rather than imply everything survived - which
is the exact failure ARCHITECTURE.md §4.7 warns about. `report <run-id>`
re-reads the recorded verdict rather than re-checking: run again next week
and you would be asking how the instance looks now, not how it looked when
it was migrated.

§4.7 said validation ran after cutover while the only implementation booted
its own copy, and listed a suite far larger than what exists. It now says
which of the two happens, and which checks are real.

ARCHITECTURE.md

@@ -340,9 +340,26 @@ no-data-loss guarantee that was not measured. See
 `internal/validate/content_integrity.go`.
 
 
-Runs automatically after cutover; failure here stops the run, reports
-loudly, and exits non-zero, leaving the operator to decide what to restore
-(§4.8).
+Runs automatically after cutover, against the service cutover has just
+started: that is the instance people will actually use — its real config,
+its real ports, under its real service manager — and checking it costs no
+extra downtime, where booting a second copy inside the maintenance window
+would. Failure stops the run, reports loudly, and exits non-zero, leaving
+the operator to decide what to restore (§4.8). The service is deliberately
+left running: by this point the store has been migrated in place, so
+stopping it undoes nothing.
+
+A check that could not be performed is reported as **skipped**, never as a
+pass. Preflight only captures the "before" snapshot when it has an admin URL
+to capture it from, and a run without one has to say it compared nothing
+rather than imply everything survived.
+
+`internal/validate.BootCheck` remains the equivalent for an instance the
+tool boots itself, which is what `rehearse` needs; `run` uses `RunLive`.
+
+Of the checks listed below, what exists today is the account/domain
+comparison. The rest are the intended shape of the suite, not a description
+of it.
 
 - **Version check**: reported server version matches the target exactly.
 - **Auth check**: WebUI login succeeds over the *configured hostname* via