feat: 2-hop swaps (u→m→v) + channel_adjacency poll hint

[YusukeShimizu]

Implements 2-hop swaps (u→m→v) where swap endpoints do not share a direct channel.

• Adds 2-hop negotiation fields (twohop container) and pins 2-hop payments via outgoing+incoming scids.
• Adds optional poll extension channel_adjacency (legacy neighbors_ad accepted on receive) to hint 2-hop candidates.
• Surfaces channel_adjacency via listpeers (LND RPC + CLN plugin) and updates docs.
• Regenerates RPC stubs and adds unit + integration tests.

Notes:

• The poll extension is advisory only (may be stale/incorrect); actual swaps still rely on explicit 2-hop discovery.
• RPC output field renamed from neighbors_ad to channel_adjacency (field number preserved).

[olegfomenko]

Hi @YusukeShimizu
I apologize in advance if this question may seem silly. I'm new to Lightning development as well as PeerSwap.
I'm wondering why you want to enable only 2-hop swaps, while the only thing we need is a direct p2p connection between peers and the possibility to find a path between them to perform either SwapIn or SwapOut. Are there any limitations that I am not aware of?

[YusukeShimizu]

In principle, multi-hop is possible, but PeerSwap prioritizes targeted liquidity movement.
2-hop is the minimal extension that expands reach while keeping the swap effect scoped and checkable via local channel state. Supporting 3+ hops would turn this into a complex routing and probing problem (unknown intermediate liquidity, higher failure rates), which is out of scope for this extension.
The proposal draft is here; I’d welcome any feedback or thoughts you might have.
#397