feat(ebpf): add usid TC-BPF program and generated bindings

[privateip]

Summary

Adds the uFMT 48+16 uSID decode/forward datapath as a TC-BPF program under internal/plumbing/ebpf/prog, plus the pure-Go primitives for its key format under internal/plumbing/ebpf/uformat:

• usid.c — the TC-BPF ingress program: exact-match lookup chain (locator → function → VRF), strip of the outer IPv6 header, and a VRF-scoped FIB lookup/redirect for the inner packet, with per-reason drop counters.
• usid_bpfeb.go/usid_bpfeb.o and usid_bpfel.go/usid_bpfel.o — bpf2go-generated Go bindings and compiled BPF objects (big/little endian), committed per this repo's convention for generated code.
• dropreason.go — exported drop-reason constants kept in sync with usid.c's enum drop_reason, for consumption by callers outside this package (e.g. a future Prometheus collector).
• doc.go — package documentation, including the go:generate directive used to regenerate the bindings.
• usid_test.go — BPF_PROG_TEST_RUN-based tests for the program.
• internal/plumbing/ebpf/uformat/uformat.go — pure-Go, no-cgo encode/decode of the uFMT 48+16 bit layout (block, node-ID, function, argument) and the locator_table/function_table key composition that usid.c implements in C, so this package is the in-repo source of truth for that key format.
• internal/plumbing/ebpf/uformat/uformat_test.go — tests for the above.

This PR is scoped to the program and its key-format primitives. The surrounding Go plumbing that will load/attach it (attach), read its maps (usidmap), and expose metrics (metrics, preflight) is intentionally left out and will land in follow-up PRs.

Testing

• task ci (lint → build → test:unit → test:e2e)

🤖 Generated with Claude Code

[ecv]

The summary says the uformat plumbing is intentionally left out and lands in a follow-up, but internal/plumbing/ebpf/uformat/ (uformat.go + uformat_test.go, ~900 lines) is in this diff. Shipping it here reads deliberate to me — usid.c's locator/function/vrf key composition is exactly what uformat encodes, so splitting them would land the program with no in-repo definition of its own key format. Just the body that's stale; worth a quick edit so the scope line matches what's actually here.

[privateip]

Good catch — the summary was stale. Updated it to reflect that uformat is in scope here: it's the in-repo definition of the locator_table/function_table key format that usid.c implements in C, so it belongs with the program rather than the follow-up plumbing PRs (attach/usidmap/metrics/preflight).

[privateip]

Closing as superseded by #281 — usid.c is byte-identical between the two, so review discussion should consolidate there.