transport: drop outlier RTT samples above MaxReasonableRTTMs (30s)

[0pcom]

Summary

Production observation post-#2415/#2418: three sudph transports show min/avg ~190ms but max ~33-35 seconds in TPD's /metrics. The min/avg are correct; the max is a single straggler pong arriving long after its ping — handleTransportPong correlates pong to ping only by timestamp, with no in-flight tracking that would discard a pong arriving after the implied timeout. Once it lands, Max only ever grows, so a single bad sample pins the transport's Max for the life of the lat:<id> key (35 days).

Real intercontinental RTT plus heavy queueing is comfortably under 5s, so 30s is a generous upper bound for "obviously bogus".

Fix

Mirror the existing zero-clobber lower-bound guard with an upper-bound at every layer:

• transport.MaxReasonableRTTMs — exported constant, 30_000.0 ms.
• SetLatency drops latencyMs > MaxReasonableRTTMs (alongside the existing <= 0).
• SetLatencyStats rejects the whole snapshot if any of min/max/avg exceeds the bound.
• handleTransportPong short-circuits before SetLatency, Trace-logs the dropped value.
• RouteGroup.MeasureLatency drops outlier samples from measurements so a stale pong from the periodic pingLoop landing in the buffered pongCh can't poison an active measurement's min/max/avg.
• RouteGroup.handlePongPacket rejects up front so neither networkStats, the synchronous pendingPongCh consumer, nor the underlying transport see the bogus value.

Test plan

• go build ./... clean.
• go vet ./pkg/transport/... ./pkg/router/... clean.
• go test ./pkg/transport/ ./pkg/router/ ./pkg/transport-discovery/... all pass.
• gofmt clean.
• New regression tests:
  • TestSetLatencyDropsOutliers — rejects the 35s production case, accepts exactly at the bound, valid samples after rejection still update the running stats.
  • TestSetLatencyStatsDropsOutliers — table test rejects partial-outlier shapes (over-bound min/max/avg in any combination), accepts a fully-in-bound snapshot.
• After deploy, in skywire cli tp metrics --by-transport: no transport's latency.max exceeds 30,000 ms; production cases like 51eced2f, f4c0e8c7, f95d6019 (currently min/avg ~190ms, max ~32-35s) settle to plausible max within ~5 minutes of a CXO push.

Followup to

#2415 (zero-clobber) and #2418 (persistent latency). The 35s outliers were the first thing visible once latency started persisting, since transient bad samples used to disappear with the registration TTL — they now stay around for 35 days.