transport-discovery: persist latency in a dedicated key, decoupled from registration TTL

[0pcom]

Summary

Latency lived inside the tp:<id> registration blob and inherited its 5-minute entry-timeout. Bandwidth has always been stored at bw:daily:<id>:<date> with a 35-day TTL, so any visor that paused re-registering (TPD restart, network blip, normal churn) silently lost its latency from /metrics until the next CXO push — while bandwidth-today survived intact. After a TPD bounce in production this is observable: bandwidth recovers as visors re-register, latency does not.

This change moves latency to a peer of bandwidth.

What's stored

• New key: transport-discovery:lat:<id>, JSON {min, max, avg, updated_at} in microseconds, 35-day TTL (latencyTTL matches bw:daily:* retention).
• TransportData.Latency{Min,Max,Avg} stays in the schema so older payloads decode cleanly, but no write touches it anymore.

Write path

UpdateLatency writes only to the new key. The "must be registered" coupling and the TTL-inheriting Set on tp:<id> are gone — those were exactly the reasons latency disappeared with registration churn. avg <= 0 still drops the update. Last-writer-wins, no per-edge tracking, no daily aggregation — only the storage location and lifetime change.

Read paths

getLatencyRecord(ctx, id) plus a batched hydrateDurableLatency([]*Entry) overlay durable values onto entry/entries:

• GetTransportMetrics (/metrics endpoint) — reads the new key directly in its existing pipeline.
• getAllTransportsWithQoS → GetNetworkMetrics, GetVisorAggregateMetrics — hydrates after scanAllTransports.
• GetTransportsByEdge (/transports/edge:, /transports/edges) — hydrates the returned slice.
• GetTransportByID (/transports/id:) — single-entry hydration.

Test plan

• go build ./... clean.
• go vet ./pkg/transport-discovery/... clean.
• go test ./pkg/transport-discovery/... ./pkg/transport/ ./pkg/router/ ./pkg/visor/stats/ all pass.
• No new unit test added — the store suite runs against newMemoryStore() (where UpdateLatency is a no-op) and there's no miniredis fixture in-repo.
• Post-deploy verification:
  • redis-cli TTL transport-discovery:lat:<id> returns ~3024000s (35d), never the 5-min registration TTL.
  • After a TPD bounce, /metrics carries latency for transports whose visors haven't yet re-pushed a CXO sample.
  • /metrics/visor, /metrics/visors, /transports/edge:, /transports/id: reflect the persisted latency.

Sequencing

Independent of #2415 (zero-clobber guards), but the two interact: #2415 prevents partial-zero snapshots from being persisted in the first place, this PR ensures whatever does land is durable.