fix(dolt): gate compact integrity on removed rows, not count/hash drift (gc-800l)

[zook-bot]

Fixes the post-flatten compact integrity check quarantining on essentially every
pass against a live city, and the blank postflight_db_value_hash field on the
resulting markers.

Problem

The integrity check compared row counts and table value hashes before/after the
flatten. Against a live city both drift on every pass from ordinary traffic, so
the first scheduled run after auto-compaction was enabled (lx, 2026-08-09)
quarantined and mailed the mayor: events gained a row and drifted (an
append-only log does that by construction), and issues drifted at an unchanged
row count (a concurrent bd update rewriting a row in place). DOLT_DIFF
across the two recorded HEADs showed modified 2, removed 0 and added 3, removed 0 — nothing was lost.

On a 24h timer that quarantines on nearly every pass, which is the same end
state as never compacting, plus recurring false alarms that train the reader to
clear markers without reading them.

Change

Counts and hashes cannot answer "was a row lost". They stay as the cheap
trigger; the verdict moves to a direct DOLT_DIFF of the preflight snapshot
HEAD against the flatten commit, counting removed rows. The existing Option A
proof (gastownhall#2846) is generalized two ways:

• it counts removed instead of every non-added row, so an in-place update no
  longer reads as unprovable;
• the category guard now admits same-count hash drift, which previously had no
  proof path at all.

Row-count decrease, table-list drift and probe failures stay excluded and keep
their existing fail-closed handling.

Also fixes postflight_db_value_hash being recorded empty: the quarantine fired
before that probe ever ran. Markers now distinguish a value from <empty>
(probed, nothing returned), <probe-failed> and <not-measured>, and the
follow-up commit adds the missing test for the <probe-failed> branch plus a
docs correction ("three states" above a four-row table).

The stricter whole-database hash comparison is deliberately not moved behind
a quiesce flag — with the verdict removal-based it is no longer a decider for
table drift, so gating it buys nothing the diff does not already settle.

Validation

Positive control both ways in the hermetic fake-dolt harness, since the two
shapes produce identical count/hash evidence and must reach opposite verdicts:

• mixed_row_count_gain_and_same_count_hash_drift (the exact lx signature) and
  same_row_count_writer now defer — no quarantine marker, no GC;
• new same_row_count_row_loss and the existing replacement scenarios still
  report removed rows and quarantine with the drift evidence recorded.

go test ./examples/bd/dolt/... and test/dolt/compact_gain_drift_proof_test.sh
(11 cases) pass; go vet ./... clean. Confirmed read-only against the live lx
store that an in-place update between two commits reports diff_type = modified
and the proof's exact query returns 0 removed rows.

Known follow-ups

• Keyless tables report an in-place update as a removed/added pair, so they still
  fail the proof and quarantine. That is the safe direction and the pre-existing
  behaviour; noted in the helper.
• The bead also asks for an end-to-end live control (a scheduled pass reclaiming
  without a quarantine). That flattens real production history, so it needs
  operator sign-off and is not run here.

Bead: gc-800l

[zook-bot]

CI attribution: zero new failures from this branch

This PR's CI is red, but every failing job is pre-existing on main — do not reject it on that basis.

Failing-job subset proof against main's own CI run 31302845132 at the same base SHA 095206f48:

	jobs
main failing at 095206f48	12
PR #107 failing	4 — CI / integration, CI / required, Integration / packages-cmd-gc-integration, Integration / rest-smoke-2-of-2
New failures introduced here	0 (strict subset)

main's CI has been failing at every recent SHA (095206f48, 3e629adc4, f7ef1def0, 2de3be851, 390624b0e). #106 is the open fix for that required gate, and it shows the identical 4-job failing set.

Note the aggregate gates (CI / required, CI / integration) fail in 3-4s — they short-circuit on the upstream job failure, so the job name reports only the first failing step, not the root cause.

The local pre-push gate on this branch was 10/10 shards green.

Recommended handling: hold until main's gate fix lands, then re-run CI here.

_{— gascity refinery, patrol wisp gc-wisp-1rs}