A transport import seam: polymorph:iroh/transport mirroring upstream's CustomEndpoint

[lannbot]

From #13's section E, filed so the seam does not ossify.

Internally, endpoint/ reinvented upstream iroh's transport abstraction almost exactly: the synthetic 2001:db8::/48 standins plus the routes table are upstream's MultipathMappedAddr ULA mapping plus Transports dispatch, independently converged. That seam is currently hardcoded to three wires (relay, UDP, WebRTC), and the world's fixed import list is the (closed) transport abstraction today.

If this family ever wants Tor/BLE/new wires as components — the thing upstream's unstable-custom-transports does natively — the move is a polymorph:iroh/transport import interface mirroring upstream's CustomEndpoint:

• send(addr, datagram)
• receive() -> (addr, datagram)
• a local-address watch

with dispatch keyed off custom-addr.id (upstream's registry convention, TRANSPORTS.md).

Two loose ends resolve here rather than piecemeal:

• path-kind's custom asymmetry (WIT review #13 finding C9): transport-addr can name a custom transport but path-kind cannot report one. Fixing it today means path-kind becomes a variant (breaking) for a capability nothing exercises; the enum grows its custom(u64) arm when this seam gives it a referent. path-changes (connection.path-changes: a coalescing watch replaces upgrade polling #57) inherits whatever shape path-kind takes.
• D16's closed-world latitude: a transport import turns "the deployment does not serve this wire" from a stubbed-import degradation (recorded at the option sites by Error taxonomy names the documented failure modes: timed-out, not-supported, in-use #59) into an explicit composition fact.

Not scheduled: this is a seam to keep clear, not surface to build now. The #14 ruling bears on it — an upstream-backed core would get the seam from upstream's CustomTransport directly, and this interface would become its projection.