hash_migrate: server-side DB writes on the read-only handle; failures logged as collisions; ghost duplicates share a hash #215

Relates to #202, #209

Problem

cmd/server/hash_migrate.go (migrateContentHashesAsync) issues UPDATE/DELETE statements from the server process. The server opens SQLite with mode=ro, so this breaks the read/write separation invariant (Kpa-clawbot#1283). The current readonly_invariant_test.go does not catch it, because it only asserts three method names.

Found during the #209 review, using reviewer-only probes against master and the #209 merged tree:

1. Every write fails on the production handle. With OpenDB (mode=ro), two stale-hash duplicates, and the migration run, every UPDATE fails.
   • Each failure is logged as collides — merging duplicate, which is misleading.
   • The DB is left unchanged, with both rows and the old hash, so the migration repeats on every server start.
2. Ghost duplicates in memory. Both transmissions take the new content hash in memory and both stay in s.packets. byHash points to only one of them, and QueryPackets returns both.
3. Shared nodeHashes entry. nodeHashes is keyed by hash. Evicting one ghost removes the shared nodeHashes[pk][hash] entry that the surviving transmission still relies on. This is inferred from the code, not probed.
4. Stale nodeHashes keys. Keys created before a migration are never removed. After both duplicates are evicted, byNode is empty, but nodeHashes still holds the relay keys under the old hashes. This applies to every byNode source, and it is bounded by migrated transmissions × relays.
5. Stale chargedBytes. After migration, chargedBytes is off by the hash length difference. It is credited consistently, so there is no drift.
6. Untested constant. perFallbackRelayBytes (added in fix(store): charge the path_json fallback and pin the hash-migration accounting (#202) #209) is not pinned by any default-run test. The mutant perFallbackRelayBytes = 0 survives every _202/_113 test, and the heap comparison that would catch it is env-gated (CORESCOPE_PERF_202).

Proposed direction

• Move the DB part of the content-hash migration (rehash, collision merge, duplicate delete) to cmd/ingestor, like every other write.
• The server should only rehash in memory. On a collision, it should merge in memory: move the duplicate's observations to the survivor, then remove the duplicate from s.packets, byTxID, byHash and the node indexes, crediting each charge exactly once.
• Re-key or remove the nodeHashes entries under the old hash during migration.
• Extend readonly_invariant_test.go, or add a test, so that a write statement from cmd/server fails the build or a test. One option is a probe that runs the migration on a mode=ro handle and asserts that no write is attempted.
• Add a default-run bound for perFallbackRelayBytes.

Acceptance

• No UPDATE/DELETE/INSERT from cmd/server for the hash migration, and a test enforces it.
• Migration on a DB with stale-hash duplicates converges once (in the ingestor) and is not repeated on the next start.
• In memory, migrated duplicates leave exactly one transmission per hash, with all observations, and QueryPackets cardinality is correct.
• After migration and eviction, byNode, nodeHashes and trackedBytes all return to the baseline exactly, without relying on the clamp.
• StoreTx stays at 320 bytes. No new map[string]interface{}.
• A test pins perFallbackRelayBytes, so the = 0 mutant is killed.