distinguish fast-open from probe echoes

[marcus-pousette-hp]

Distinguish ordinary holepunch probes from the responder's intentional fast-open confirmation. [0] remains the probe and coordinated-punch payload, while [1] confirms fast-open after NAT analysis.

Initiator	Responder	Result
Old	Old	Existing behavior, including the premature-open bug
New	New	Probe echoes cannot prematurely select a socket while fast-open remains available
Old	New	Fast-open is preserved because existing initiators accept [1]
New	Old	Falls back to coordinated punching because the old responder's pre-punch [0] is ignored

For New → Old, compatibility depends on coordinated punching succeeding. If punching is rejected or unavailable, the connection can fail rather than only become slower. Both mixed-version directions are tested against HyperDHT 6.33.1

co-authored with AI