fix(foundation): Deferred.__init__'s proto type is too narrow for transport-keyed reassembly #2417

Describe the bug

Deferred.__init__ (pcapkit/foundation/reassembly/data/data.py) types its proto parameter as 'TransType' and documents it as "Payload protocol type", but TCP.submit (pcapkit/foundation/reassembly/tcp.py) passes a port pair ((bufid[1], bufid[3])), not a TransType — because Transport.analyze overrides Protocol.analyze(proto: int, ...) to analyze(ports: tuple[int, int], ...).

At runtime, Deferred.proto for a TCP reassembly holds a tuple like (12345, 443), not a TransType member. The IP reassembler is the only caller that actually passes a real TransType.

To Reproduce

mypy independently flags the call site:

Argument 2 to "Deferred" has incompatible type "tuple[Any, Any]"; expected "TransType"

in TCP.submit.

Expected behavior

Widen Deferred.__init__'s proto annotation (and docstring) to cover both cases — e.g. 'TransType | tuple[int, int]' — or introduce a narrower per-reassembler type if the class is meant to be specialized per transport.

Additional context

Found and verified during this session's #1103 prose sweep (a real type/behavior gap, out of that sweep's prose-only scope). Behavior itself is fine; only the annotation and docstring are wrong for the TCP/transport-keyed case.