hash migration (server): distance index keeps the old time when a merge moves FirstSeen back

[dborup]

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

After an in-memory merge, cmd/server/hash_migrate.go (code) calls updateDistanceIndexForTxs only for survivors whose PathJSON changed. When the merge moves FirstSeen earlier but the path stays the same, the distance index keeps the old time. The review's reproduction moves a packet from 13:29 to 11:29, but the distance graph's time field and hour bucket stay at 13:29.

Expected

Refresh the distance index for survivors whose FirstSeen moved, as well as for those whose path changed.

Tests

• A merge that moves FirstSeen without changing the path: the distance entry has the new time and hour bucket.
• The mutant that updates only on a path change must fail.

[dborup]

Fixed by #297 (merged as 15862ea6). Review nit 1 (a merge that moves first_seen AND changes the path; XOR mutant survives) is tracked in a follow-up.