fix(core): scope the state-sync truncate to the tables the snapshot restores

[rickyrombo]

The bug

Before loading a snapshot, the restore truncates every table in the public schema:

"SELECT tablename FROM pg_tables WHERE schemaname='public' ORDER BY tablename"
// then: TRUNCATE TABLE <each> CASCADE

The reason it truncates at all is narrow, and the comment says so: the node runs migrations at startup, which populates core_db_migrations, and pg_restore's COPY then fails on duplicate keys.

But only stateSyncSnapshotTables is ever dumped. Truncating a table the dump doesn't contain cannot prevent a COPY conflict, because nothing will COPY into it. Every table outside that list was being destroyed for no reason at all.

What that costs

Core and mediorum share one OPENAUDIO_DB_URL and therefore one public schema, so the collateral is mediorum's data. Any node that state syncs loses:

Table	Recovery
blobs	relists from the bucket
uploads	eventually refills via scrollUploadsFromPeers
audio_previews	recomputed from audio — findMissedJobs → generateAudioPreviewForUpload
qm_audio_analyses	recomputed on demand
upload_cursors, repair_trackers, delist tables	reset

Nothing is permanently lost, but the last two are real CPU, on every node that joins. This matters most during a fleet-wide event where many nodes state sync at once — they all start regenerating simultaneously.

The fix

Truncate the intersection of stateSyncSnapshotTables with the tables that actually exist, in a single statement, without CASCADE.

The intersection is needed because pgRestore("pre-data") deliberately tolerates schema drift ("pre-data errors (missing tables from schema drift) are non-fatal"), so a listed table may not exist locally. Naming a missing table would fail the whole statement.

Dropping CASCADE is deliberate. CASCADE follows foreign keys outward: a key from a non-snapshot table into a snapshot table would silently truncate the non-snapshot table too — this same bug through a different door. Truncating the set together in one statement satisfies foreign keys among its members, and if something outside the set references something inside it, this now fails loudly. That's the outcome we want.

Tests

Three, all database-free so they run in CI, following the existing state_sync_snapshot_tables_test.go pattern:

• non-snapshot tables (mediorum's, etl_*) are never named, while core_db_migrations — the table that motivated truncating in the first place — still is
• only tables that exist are named; empty input yields no statement
• no CASCADE, and exactly one TRUNCATE

Verified they fail against the previous behaviour, not just pass against the new one:

--- FAIL: TestTruncateStmtSkipsTablesTheSnapshotDoesNotCarry
    truncate statement names "uploads", which no snapshot restores -- truncating it only destroys data
    truncate statement names "blobs", ...
    truncate statement names "audio_previews", ...

Scope

Behaviour change is confined to which tables get truncated during a state-sync restore. The dump, the COPY, and the restore sequence are untouched.

One thing deliberately left out: etl_* tables are chain-scoped and preserving them across a chain switch leaves stale rows. Today they are cleared as a side effect of this workaround — right for the wrong reason. If that needs to hold it should be an explicit "chain changed, clear ETL state" check rather than a byproduct of a COPY fix, and it is moot while no node runs the ETL.