hash migration: merging a transmission with a NULL route_mask turns it into 0, so route flags are lost permanently #287

Found in a post-merge review of #222 and confirmed by reading master 34f672c6.

mergeTransmissions in cmd/ingestor/hash_migrate.go (code) sets route_mask = COALESCE(route_mask, 0) | COALESCE(loser.route_mask, 0) unless both are NULL. A NULL route_mask means the value has not been computed yet; it does not mean 'no routes'. If only one side is computed, the result is non-NULL, so the route-mask backfill skips the row afterwards. The routes of the side that was not yet computed are lost for good. The review's reproduction ends with DIRECT only, although the packet was also heard as FLOOD. A restart does not repair the stored value.

Expected

• If either side is NULL, the merged route_mask must stay NULL, so the backfill recomputes it from all observations of the survivor. Alternatively, recompute it from the merged observations in the same transaction.
• Check other columns in the same merge for the same NULL-means-unknown pattern.

Tests

• Survivor computed (DIRECT) + loser NULL (heard as FLOOD), then merge, then backfill. Expected mask: DIRECT|FLOOD.
• The mutant that restores COALESCE(…,0) must fail.
• Note: the one-time migration content_hash_formula_v1 has already run on existing deployments. Say in the PR whether already-merged rows can be repaired, for example by forcing a route_mask recompute, or explain why that is not needed.