feat(state): drop SQLite history after a verified DuckDB import #1143

After a successful DuckDB history import, SQLite still keeps history_hot / history_warm / history_cold / ts_samples (and ledger tables). A box with ~20M samples then stores the same rows twice until someone vacuums by hand.

Found while reading draft PR #1129 (feat/duckdb-history, 1bd31f6b). Do not rewrite those files out from under that PR; this is a gate for the same change.

What happens

openHistory copies every history table from SQLite, verifies count and hash, then binds history_duckdb_generation. Live reads and the queued writer use DuckDB.

migrate() in go/internal/state/store.go still CREATE TABLE IF NOT EXISTS the SQLite history tables. There is no DROP after a verified import. Snapshots already omit those tables (store_test.go checks sqlite_master has none). The live state.db does not.

Schema 3 already requires a full backup, so dropping after verify is recoverable via that backup. Leaving the tables:

• doubles disk on the Pi
• keeps the SQLite integrity gate and VACUUM paying for dead rows
• invites an old code path to read stale SQLite history if a query is missed in the cutover

What a fix needs

• After generation bind and verify, drop the SQLite history/sample/ledger tables (or equivalent migrateLegacyHistorySplit) and VACUUM or CompactIfBloated.
• Refuse to drop if DuckDB verify failed or generation is unbound.
• Tests: import → SQLite history tables gone → DuckDB readback intact → image-only downgrade still refused.
• Land on feat(storage): use embedded DuckDB for primary history #1129, not as a parallel master patch.

Related: #882 (batch ledger SQL on the control tick). #1129 moves that I/O off the tick into DuckDB; dropping SQLite history is the disk half of the same cutover.