fix(reassembly): a datagram whose header plus data exceeds 65,535 octets still reads COMPLETE #1585

These are follow-ups from the #1582 cross-review, both in pcapkit/foundation/reassembly/ip.py.

1. A datagram longer than the protocol allows still completes.
   • Repro: case 3c of the fix(reassembly): a TSO fragment's length is its captured length, and RCVBT covers the last block (#1555, #1565) #1564/fix(reassembly): only the final fragment's partial block counts, and an oversized datagram never completes (#1566, #1567) #1582 repro. The fragments' data covers 0–65,522, so TDL is 65,523 and the 20-octet header brings the total to 65,543. That is over IPv4's 65,535 limit, yet the datagram reads COMPLETE, on fix(reassembly): only the final fragment's partial block counts, and an oversized datagram never completes (#1566, #1567) #1582's head and on main alike.
   • Linux: ip_frag_reasm rejects this case (len = ip_hdrlen(skb) + qp->q.len; if (len > 65535) goto out_oversize).
   • Expected: a header-aware bound, len(header) + TDL <= 65535, with the IPv6 equivalent for the Payload Length limit. A datagram over that bound reads PARTIAL or is flagged, rather than COMPLETE.
2. The _detect_conflicts docstring is stale since fix(reassembly): only the final fragment's partial block counts, and an oversized datagram never completes (#1566, #1567) #1582.
   • What it says: a non-final fragment's range is always block-aligned.
   • What happens now: since fix(reassembly): only the final fragment's partial block counts, and an oversized datagram never completes (#1566, #1567) #1582, a non-final fragment's cut tail is written to the buffer but not marked received. A later fragment that disagrees with those octets therefore records no conflict.
   • Expected: either detect the conflict, or document that the case is deliberately ignored.

Blocked until #1582 merges, because it changes the same file.