fix(server): accept v6 peers on default-IPv4 allocations for dual-stack relays

[ti]

Problem

internal/server/turn.go ipMatchesFamily strictly rejects pure-IPv6
peer addresses against an IPv4 allocation, including the default
IPv4 allocation that pion/turn applies when an Allocate request
omits REQUESTED-ADDRESS-FAMILY (RFC 6156 §4.1.1).

Browser WebRTC TURN clients (Chrome, Firefox, Safari) never set
REQUESTED-ADDRESS-FAMILY in their Allocate requests, so on a
dual-stack or IPv6-only Linux host every browser-driven allocation
ends up IPv4-family even when the listener and relay sockets are
bound [::]. Subsequent CreatePermission/ChannelBind requests
with v6 peer addresses are then rejected with
errPeerAddressFamilyMismatch (logged at Info level, easy to
miss), and the very first Send-indication fails with
errNoPermission.

This is the canonical failure mode for pion/turn-based TURN servers
deployed in front of IPv6-only Kubernetes pod networks. With the
relay socket actually bound dual-stack on Linux (net.ipv6.bindv6only=0,
which is the default), v6 peer reachability is fine; only the
protocol-level family check blocks the permission.

Repro & root-cause

Detailed write-up + minimal repro in #566.

Short version: with a Linux dual-stack relay socket and a v4-default
allocation, peer reachability works in both directions but
ipMatchesFamily(v6-peer, IPv4-family) returns false ⇒ no
permission ⇒ no Send-indication forwarded ⇒ WebRTC PC times out.

Fix (this PR)

Relax the v4-default branch of ipMatchesFamily to also accept v6
peers, matching what a dual-stack relay socket can actually deliver.

 if family == proto.RequestedFamilyIPv4 {
-    return ip.To4() != nil
+    return ip.To4() != nil || (ip.To4() == nil && ip.To16() != nil)
 }

The symmetric IPv6-allocation case is unchanged: a v4 peer on a
v6-explicit allocation is still rejected, preserving RFC 6156
strict-mode for the case where the client opted into v6 by sending
REQUESTED-ADDRESS-FAMILY=IPv6.

Refresh request family handling is untouched.

Tests

internal/server had two assertion sites baked to the strict cross-
family rejection. They are updated to match the new permissive
behavior:

• TestIPMatchesFamily/IPv6 and /IPv6Loopback: ipMatchesFamily(v6, RequestedFamilyIPv4) now returns true.
• TestHandleChannelBindRequest/PeerAddressFamilyMismatch is renamed
  to CrossFamilyV6PeerOnV4Alloc and asserts the success response
  (the previous request flow now produces ClassSuccessResponse
  instead of 443 PeerAddrFamilyMismatch).

All other tests in ./... pass unchanged.

Caveats / alternatives discussed in #566

This is the simplest of the three options I sketched in #566. The
other two would be more conservative:

1. Default the allocation family to the listener's family when
   REQUESTED-ADDRESS-FAMILY is absent — backwards-compatible for
   IPv4-only deployments, correct for IPv6-only listeners.
2. A Server config knob (PermissiveAddressFamily bool or
   similar) that opts in to relaxed cross-family. RFC 6156 strict
   stays the default.

I went with the simplest patch first because it fixes the canonical
deployment case with the smallest diff. Happy to refactor to either
option (1) or (2) if maintainers prefer — let me know.

Compatibility note

This subtly changes behavior for clients that explicitly relied on
the v4-default + v6-peer = 443 response to detect IPv6 capability.
In practice no real-world TURN client does this (they all either
omit the attribute or explicitly request a family); but worth
flagging for review.

Refs: #566

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.54%. Comparing base (f8c9cf8) to head (4312920).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #567      +/-   ##
==========================================
- Coverage   81.73%   81.54%   -0.19%     
==========================================
  Files          46       46              
  Lines        3197     3197              
==========================================
- Hits         2613     2607       -6     
- Misses        382      386       +4     
- Partials      202      204       +2     

Flag	Coverage Δ
go	81.54% <100.00%> (-0.19%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rg0now]

See #566 (comment)