Unify Subscribe RequestSub and SeekNode message variants

[sanity]

Problem

Subscribe currently uses two nearly identical message variants:

• : initial hop (first leg), minimal fields, no skip list/htl/retries.
• : forwarded/retry form that carries skip list, HTL, retries.

Routing is already connection-based (uses upstream transport addr), so the split is legacy/convenience. The first leg is not meaningfully different from subsequent legs: each hop tries to register, and if it can’t, forwards to another peer with loop/TTL controls.

Maintaining two variants adds code paths and increases risk of divergent behavior (e.g., address handling). It also keeps payload complexity without clear benefit.

Proposal

• Collapse RequestSub and SeekNode into a single Subscribe message that always carries search metadata (skip list, HTL, retries) initialized on the first hop.
• Keep subscriber identity for registration, but treat routing as fully connection-based (use upstream transport addr, not embedded addresses).
• Simplify logic and message shaping; reduce code duplication in subscribe handling.

Context

• Raised during review of PR stack 2167-2175 (connection-based routing/NAT fixes). This simplification is out of scope for that stack but would clarify the protocol and reduce special cases.

Notes

• Ensure skip/htl defaults cover the first hop (e.g., HTL initialized from config; skip initialized with self/requester).
• Audit tests that assume distinct RequestSub vs SeekNode handling.

Labels: enhancement, networking

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-enhancement (95% confidence)
• E-medium (80% confidence)
• A-networking (95% confidence)
• S-needs-design (80% confidence)

Reasoning: The issue proposes collapsing two existing message variants into a single Subscribe message and simplifying routing/registration logic — this is an improvement/refactor of existing protocol behavior rather than a new feature or a bug, so T-enhancement fits. The change touches protocol message formats, routing behavior, and tests, which suggests moderate complexity (E-medium). The modifications are squarely in networking/routing code (A-networking). The proposal is architectural and should be discussed/reviewed before implementation, so marking S-needs-design is appropriate.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.