policy: include CapGrant destinations for peer relay capabilities

[wangrzneu]

Changes

Extend MatchFromFilterRule in hscontrol/policy/matcher/matcher.go to union CapGrant[].Dsts into the rule's destination set. Without this, a node that only receives capabilities (e.g. cap/relay, cap/relay-target) through a CapGrant is excluded from the grant issuer's peer map, which breaks peer relay on grant-only policies.
Close: #2841

Peer Relay Test Method and Results

Method

• Objective: verify in a real environment that 100.64.0.2 and 100.64.0.4 can use peer relay through 100.64.0.3 when direct UDP connectivity is
  blocked.
• Environment:
  • 100.64.0.2: headscale-server on 107.150.110.155
  • 100.64.0.3: relay node on 123.58.213.16 / 10-7-54-172
  • 100.64.0.4: client node on 10-60-53-172
  • Headscale was upgraded to the current branch build before testing.
• Method:
  • Verified the baseline path was direct.
  • Added temporary iptables rules on both ends to block UDP 41641 between 0.2 and 0.4.
  • Configured the relay node to listen on 40000 and advertise 123.58.213.16:40000.
  • Re-tested with tailscale ping, tailscale status, and tailscale debug peer-relay-sessions.
  • Removed the temporary firewall rules after the test.

Result

• Direct connectivity was successfully forced off.
• Both directions switched to peer relay:
  • 0.2 -> 0.4: via peer-relay(123.58.213.16:40000:vni:1)
  • 0.4 -> 0.2: via peer-relay(10.7.54.172:40000:vni:1)
• On the relay node, tailscale debug peer-relay-sessions showed an active session and increasing packet counts.
• After removing the temporary blocks, the nodes returned to direct connectivity.

Conclusion

• Real-world end-to-end peer relay is working.

Check List

• have read the CONTRIBUTING.md file
• raised a GitHub issue or discussed it on the projects chat beforehand
• added unit tests
• added integration tests
• updated documentation if needed
• updated CHANGELOG.md