fix(storage): drop the five retired share-batch-chain tables (#585)

[defenwycke]

First substantive step on #585 after the backup pruning in #826.

What this reclaims

SBC was deleted in #703, the share_batch_shadow flag is gone from config, and #692 closed on 2026-08-22. The data outlived the feature. Measured on ghost-vm5 today:

table	rows	size
sbc_batches	1390	133 MB
sbc_certs	1389	2 MB
sbc_watermarks	6	~0
sbc_balances	5	~0
sbc_quarantine	1	~0

~135 MB per node, ~1.1 GB fleet-wide. sbc_batches dominates because each row stored verbatim JSON — roughly 95 KB apiece.

Verified first: outside migrations.rs, the only mentions of any of these tables are two doc comments in shard_store.rs comparing the shard's design to SBC's. No read path, no write path, no flag to re-enable it.

Why this doesn't use v57's "must be empty" guard

migrate_v57 refuses to drop a non-empty wraith_bonds because every row was escrowed value — dropping it would silently release or strand sats. That reasoning is about money, not a blanket rule. These rows are retired accounting history for a mechanism the shard replaced.

⚠ The bug a test caught in my own verification

The migration verifies its work rather than assuming it. My first version read:

SELECT COUNT(*) FROM sqlite_master WHERE name LIKE 'sbc_%'

That is blind to what it claims to check — the indexes are idx_sbc_* and sqlite_autoindex_sbc_*, so a name-prefix match catches none of them, and the check would report success with orphaned indexes still in the schema. It now also matches on tbl_name (the table an index belongs to) and escapes the _ wildcard so it asserts the real prefix.

Control	Result
Leave an index undropped, current check	test fails
Leave an index undropped, old name-only check	test passes ← the bug

Two existing tests inverted, not deleted

v50_stores_balances_... and v53_applies_on_v52... both asserted these tables were present at head. Both are flipped to assert they're gone, so a future migration recreating them has to argue for it. The v50 replacement carries a control asserting the shard tables that replaced SBC do exist — otherwise it would pass just as happily against a database that failed to migrate at all.

⚠ Frees pages, does not shrink the file

auto_vacuum=0 and the freelist is essentially empty, so the space is reused internally and growth slows — the file does not get smaller. Returning it to the OS needs VACUUM, which wants twice the DB free and took ghost-vm6 down once. Deliberately not done here; tracked separately on #585, where it is now affordable (23–25 GB free vs a 3.7 GB DB).

cargo test -p ghost-storage --lib: 234 passed, 0 failed. Clippy and fmt clean.

Deploy note

Bumps SCHEMA_VERSION to 59, so a migration runs on each node at next roll. v58 took ~81s and left a WAL high-water mark; this is a set of DROP TABLEs rather than a column rewrite, so it should be cheaper, but expect the same WAL behaviour.

https://claude.ai/code/session_01Td1vvfowptTTnu88qG2iym