fix: Prime gateway ARP/NDP neighbor for eBPF fib lookup

[privateip]

Summary

The eBPF uSID ingress datapath (added in #285) decapsulates SRv6 traffic and calls bpf_fib_lookup() to resolve the egress path for the inner packet, then redirects it straight to the resolved neighbor — entirely in-kernel, never touching the normal forwarding stack. bpf_fib_lookup() does not itself trigger ARP/NDP resolution the way ordinary kernel packet forwarding does, so without a pre-existing neighbor table entry it fails with BPF_FIB_LKUP_RET_NO_NEIGH and the datapath drops the packet. In practice: every cross-region packet to a pod that had never otherwise triggered NDP for its own address was silently and permanently blackholed.

installGatewayNeighbor fixes this by installing a permanent neighbor table entry mapping the pod's address to its guest veth's own known MAC at CNI ADD, so this resolution never depends on dynamic ARP/NDP. The guest MAC now flows from buildVethResult through publishBGPState into configureHostGateway; it's nil for tap attachments, which have no separate guest-side link in this netns to resolve a MAC from — that path is out of scope here since this fix targets the veth-only bug it was found from.

Stacked on #285 since the neighbor entry only matters once the eBPF datapath is the one performing the fib lookup.

Test plan

• go build ./...
• go vet ./...
• go test ./internal/cni/... (one pre-existing unrelated failure: TestUpdateForwardRuleInvalidAction needs an iptables binary not present in this sandbox)
• task lint (0 issues)

Part of the eBPF uSID datapath cutover stack (base: #285).

[ecv]

Same disclosure as on the rest of the stack — ecv reviewed this through an AI shell, apologies. Two questions.

1. This primes the neighbor entry for veth only; tap passes nil and skips it. The comment says tap is out of scope because there is no guest-side link in this netns to read a MAC from, which I follow — the guest picks its own MAC, so the fix is not simply symmetric. But feat: Cut CNI ADD over to eBPF uSID registration #285 registers tap attachments into vrf_table with their own egress kind, and feat(ebpf): add usid TC-BPF program and generated bindings #280's docs call both modes supported, so a tap attachment reaches the same bpf_fib_lookup with the same empty neighbor table. Does it blackhole the same way until the VM happens to send something that resolves it? If it does, is "supported" the right word for tap until that path has an answer too?

2. The comment attributes the drop to DROP_REASON_FIB_LOOKUP_FAILED, but usid.c maps BPF_FIB_LKUP_RET_NO_NEIGH to DROP_REASON_FIB_NO_NEIGH and only falls through to FIB_LOOKUP_FAILED for return codes it does not name. Anyone chasing this bug from the metrics would watch the wrong series. Worth correcting the comment — and the distinct counter is what made the diagnosis possible, so it is worth naming right.

[ecv]

i'll pause now