Strip PeerKeyLocation payloads from Subscribe messages #2183
{{ message }}
PeerKeyLocation for target/subscriber, even though routing is now connection-based by socket address. Using PeerKeyLocation (with embedded addresses) for connected peers is redundant and risks stale/wrong addresses being propagated.\n\n## Why it matters\n- We identify live peers by SocketAddr now; the transport source (upstream_addr) is authoritative for routing ReturnSub.\n- Embedded addresses can be wrong (NAT loopback/private) and should not be trusted.\n- Carrying a full location in payload forces us to thread addresses we don’t actually use.\n- PR #2174 surfaced a regression where trusting a Known-but-wrong embedded address breaks NAT peers; overriding from transport source fixed it, but removing embedded addresses would prevent the class entirely.\n\n## Proposal\n- Keep subscriber identity (pubkey/PeerId), but drop/ignore embedded addresses in Subscribe payloads.\n- Treat routing as fully connection-based: return path uses upstream_addr; forward path uses selected next-hop socket address.\n- Adjust add_subscriber/ring/seeding code to accept identity + observed upstream address instead of a full PeerKeyLocation payload.\n- Consider merging RequestSub/SeekNode (see #2182) so the message shape is simplified in one pass.\n\n## Scope\n- Out of scope for PR stack 2167–2175; track as follow-up cleanup.\n\nLabels: A-networking, T-enhancement\n