fix: gate the snapshot-seed signers pass on the versions we already hold

[karolko9]

What

snapshot-seed's signers pass (account_entry_state) emitted the full live-account set on every run — no comparison against what the database already holds. Right when written (the live signers writer did not exist yet), wrong since that writer deployed: on the second production pass every other correction collapsed to churn while this one re-emitted 10.9M identical rows, so its summary line was a constant that could not carry a signal.

The pass now reads max(last_updated_ledger) per account (sliced on the key like every other read here, RMT-deduplicated) and emits only accounts the snapshot holds newer. The summary reports written and skipped-as-unchanged, and the two sum to the snapshot's live-account count.

Verified

Production dry-run at checkpoint 64,237,951 (read-only): 0 written, 10,909,433 unchanged, sum equal to the snapshot's live accounts to the row. A later pass that writes millions again now means the live signers writer stopped stamping — which is the point.

Deliberately out of scope

• No floor on the version read — the one input here that fails toward re-emitting (harmless under ReplacingMergeTree) rather than toward manufacturing rows; a floor would also refuse the legitimate first-seed/empty-table case. Explained in place.
• No content diff at equal versions — that is the 0503 audit's job, and a heavier read (three arrays per account for 10.9M accounts).

Checks

• gate regression test (4 cases), cargo clippy --all-targets -D warnings clean
• docs: docs/backfills.md gains the signers-gate paragraph
• API types: N/A — nothing under crates/api/**

[karolko9]

Superseded by #568: task 0210 split the seed passes into modules, so the same gate is rebuilt there (snapshot/entry_state.rs).