fix: stop duplicate detection dropping distinct packets that share a 64-byte prefix

[Chessing234]

Replay and duplicate detection in SecurityManager keyed on this:

val payloadHash = packet.payload.sliceArray(0 until minOf(64, packet.payload.size)).contentHashCode()
"${packet.timestamp}-$peerID-$payloadHash"

A 32-bit contentHashCode over at most the first 64 bytes of the payload. Two packets from the same peer in the same millisecond that agree on that prefix are the same packet as far as this cache is concerned, and a collision here is not a false alarm — it is a dropped message. validatePacket returns false, the packet is discarded, and nothing anywhere reports that it happened.

Why this is worth changing rather than tuning

The repo already has the right answer to "are these the same packet". PacketIdUtil — first 16 bytes of SHA-256 over type, senderID, timestamp and the whole payload — is what GossipSyncManager uses for sync membership and what MessageHandler uses to assign message IDs. iOS derives it identically (bitchat/Sync/PacketIdUtil.swift), so it is also the cross-platform notion.

So the security path was carrying its own weaker private definition while the strong one sat in the same source tree, already used for the same question. Using it makes the two agree, and the FRAGMENT special case disappears on the way — it existed only because the general branch truncated at 64 bytes, and the full payload is covered either way now.

Peer scoping is deliberately kept. PacketIdUtil covers the packet's own senderID, which is not the same thing as the peer it was received from once a packet has been relayed, so the key stays "$peerID-$packetId" rather than becoming the bare packet ID.

What is not claimed

This is not a fix for a forged-packet attack. validatePacket already records only packets that pass signature verification, with a comment explaining exactly why, so an attacker cannot poison the cache against a peer without that peer's signature. What changes here is accidental collision between two honest packets, and the fact that the security layer and the sync layer no longer disagree about packet identity.

Verification

Local run of the CI job (testDebugUnitTest lintDebug, JDK 21). Counts from --rerun-tasks on both sides so they are real full-suite runs, not incremental leftovers:

• 608 → 611 tests, 0 failures, lint clean. Per-class diff shows one class changed — SecurityManagerTest, 24 → 27 — and nothing else moved.
• The collision test fails on unmodified main, which is the point: two packets sharing a 64-byte prefix and a timestamp, second one silently dropped.
• The other two pass before and after by design — replay of an identical packet still rejected, and the same packet from two different peers still tracked separately. They are there so that strengthening the identity cannot quietly weaken what the cache exists to do.

CI has not run. Fork PRs here sit at action_required until a maintainer approves the workflow, so the local run is the evidence, not a green check.