[Bug] Retransmitted QoS2 PUBLISH packets are delivered twice with new downstream packet IDs #7919

Behavior and reproduction

At fda742c48e7f553c9964cf74b36732326d0fde00, an inbound QoS 2 retransmission is forwarded as a new publication instead of being recognized as the same in-flight message.

Executed using the real Publish handler, SubscribeRepository, a connected publisher and a Netty EmbeddedChannel subscriber:

1. Subscribe at QoS 2 to qos2/probe.
2. Send a PUBLISH with QoS 2, packetId 77, DUP false and payload payload.
3. Wait for the first forwarded PUBLISH.
4. Before any PUBREL, resend the same PUBLISH with packetId 77 and DUP true, as a client does when recovering the QoS 2 handshake.
5. Observe a second forwarded PUBLISH. The subscriber-side packet IDs are 1 and 2, so this is not one downstream QoS 2 retransmission that a subscriber can deduplicate.

The probe used latches for asynchronous send completion, not sleeps, and released inbound/outbound message buffers. The server's correct PUBREC packet type does not prevent duplicate application delivery.

Location and cause

• Every incoming PUBLISH schedules send before checking handshake state
• QoS 2 branch sends PUBREC but stores no in-flight receive state
• Each send assigns a fresh subscriber packet ID
• PUBREL only sends PUBCOMP

No per-session receive-side QoS 2 state suppresses duplicate packet IDs between PUBLISH/PUBREC and PUBREL/PUBCOMP.

Expected behavior / suggested repair

Track receive-side QoS 2 exchanges per client/session, acknowledge retransmitted PUBLISH without delivering it again, and complete/release state at the appropriate PUBREL/PUBCOMP boundary. Define persistent-session/reconnect handling and cleanup. Test retransmission both before and after handshake steps, and assert exactly one downstream application publication.

Medium severity, high confidence. Distinct from closed #6743, which corrected PUBACK to PUBREC; the current code already sends PUBREC, while the handshake deduplication/state machine is still absent. Wildcard/SUBACK/retained-message issues do not cover this path.