pkg/routing: unbind WireGuard TUN from VRF on teardown/rebind (#5120)

[psaab]

Closes #5120

Problem

applyWireguardTunLocked (pkg/routing/tunnel.go) bound the persistent
wgN TUN to a VRF only in the non-empty routing-instance case and
had no else/unbind branch. The WG config-removal prune in Apply
reconciled only addresses (#1919), never VRF membership. WireGuard also
bypassed the identity-gated appliedRI claim machinery every other
tunnel (GRE/IPIP/anchor) uses.

Result: removing the routing-instance stanza from a still-configured
WG tunnel — or removing the whole persistent tunnel — left wgN
mastered to the old vrf-<name> indefinitely. Traffic then stays
isolated in / leaks through the wrong routing table after a successful
commit, carried by the persistent interface. The source comment on
origin/master explicitly conceded the gap (boundary (3), #1434).

Verified GENUINE on current origin/master (b6703ee9a): the WG bind at
tunnel.go was a bare if tc.RoutingInstance != "" { Bind... } with no
unbind, and the prune loop only called pruneAppliedAddrsLocked.

Fix

Route WireGuard through the same identity-gated claim machinery as
other tunnels:

• applyWireguardTunLocked now calls reconcileVRFClaimLocked (records
  appliedRI on a successful bind; identity-gated-unbinds when the
  desired RI is empty on a still-configured tunnel).
• Extract the unbind tail of reconcileVRFClaimLocked into a shared
  unbindVRFClaimLocked(name, link) -> retry. It clears the master only
  when the link's CURRENT master is the claimed RI's vrf- device
  (never a foreign bind), clears the claim on success / master==0 /
  identity-mismatch / VRF-not-found, and retains the claim
  (retry=true) on a transient VRF-lookup or LinkSetNoMaster error.
• The persistent-link removal prune in Apply calls
  unbindVRFClaimLocked on the KEPT wgN link and folds its retry into
  the existing address-prune retry (retaining the wgConfigured entry
  for the next Apply). A not-found device clears the claim.
• Preserve appliedRI across the non-WG→WG same-name handoff so a
  reused anchor TUN's prior VRF claim carries into the WG reconcile
  (else an anchor→WG-no-RI device would strand its old master). A
  GRE→WG handoff recreates the link (master==0), so the carried claim
  self-clears.

The wgN link itself is still KEPT on removal (#1432 S2a — tearing it
flaps the live peer/session); only the stale VRF enslavement is cleared.

Tests (RED-on-revert proven)

Four new tests in tunnel_reconcile_test.go:

• TestWireguardVRFUnboundOnConfigRemoval — bind, then whole-tunnel
  removal → wgN kept, LinkSetNoMaster issued, master 0, claim
  cleared, idempotent.
• TestWireguardVRFUnboundOnRoutingInstanceRemoval — RI stanza removed
  from a still-configured tunnel → unbound.
• TestWireguardVRFForeignMasterNeverUnbound — a claim-less WG tunnel
  with a foreign master is never unbound (identity gate).
• TestWireguardVRFUnbindTransientRetried — a transient
  LinkSetNoMaster failure retains the claim + wgConfigured and
  retries to success.

RED-on-revert: git stash of tunnel.go alone (tests kept) →
the removal, RI-removal, and retry tests FAIL (appliedRI never
recorded, noMaster=[]). The foreign-master safety guard passes both
ways by design. Restored → all four PASS.

Validation

• go build ./... exit 0
• go test ./pkg/routing/... PASS (full package, not just new tests)
• go vet ./pkg/routing/... clean
• gofmt -l clean on touched files
• Updated pkg/routing/README.md (WG-removal-prune + VRF-claims
  sections; dropped the Implement Multi-Tunnel WireGuard Support #1434 "VRF membership is not unbound" residual)

No cluster smoke (per task scope — control-plane netlink reconcile,
covered by the seam tests).

🤖 Generated with Claude Code

https://claude.ai/code/session_015oARShYtiJJ2H4UB4nXGqi

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[psaab]

@copilot review