Build local service-route intent for VPC attachments

[scotwells]

Summary

Implement private service connectivity entirely in Galactic's TC-eBPF dataplane. PreferNodeLocal uses a ready producer on the consumer node when available and otherwise tunnels to a deterministic ready remote producer. Consumer instances use their ordinary default route and receive no service-specific Linux routes.

Dataplane

• Preserve the original consumer source IP across remote request and reply paths with a versioned, direction-tagged service shim over the SRv6 underlay.
• Key routes and authorization by attachment ifindex, service IP, protocol, and port; multiple services may share a VIP.
• Validate remote requests against a 128-bit grant and the expected consumer SID, then revalidate replies on both producer and consumer nodes so revocation is immediate.
• Reject ambiguous overlapping five-tuples fail-closed and replace stale reverse state immediately after its prior grant is revoked.
• Account for the full 60-byte tunnel overhead in MSS clamping and PMTU errors.
• Use the live shared uplink map, reject uninitialized source SIDs, and remove reverse state when delivery fails.
• Skip NPT/VIP translation for service tunnels so the inner source and destination remain unchanged.

Control plane and rollout

• Select ready and programmed producer attachments deterministically, preferring node-local replicas and falling back remotely only for PreferNodeLocal.
• Resolve consumer and producer End.DT46 SIDs from BGPVRFInstance and BGPRouter state.
• Reconcile routing dependencies without publishing node-local readiness failures as shared policy invalidity.
• Recreate only incompatible pinned maps, preserve unrelated live maps, and periodically detect map replacement to reconstruct desired service state.

Network PR #27 provides the API contract.

Validation

go test ./internal/plumbing/ebpf/prog ./internal/plumbing/ebpf/serviceroutemap ./internal/plumbing/ebpf/attach ./internal/serviceroute ./internal/controller ./cmd/galactic-router -count=1
go vet ./internal/plumbing/ebpf/prog ./internal/plumbing/ebpf/serviceroutemap ./internal/plumbing/ebpf/attach ./internal/serviceroute ./internal/controller ./cmd/galactic-router

The tests run on Linux with root capabilities and exercise verifier loading, source-preserving remote encapsulation, tuple-scoped map writes, state rollback/revocation, deterministic fallback, SID resolution, and selective pinned-map replacement.

[privateip]

Two changes on main now overlap this PR's changes to attach.Start and attach.Load, so a rebase will conflict there.

• fix: Keep eBPF map contents through a datapath upgrade #775 (merged) makes Load recreate only the maps whose layout changed, through a shared helper in the new mappin package. It replaces the per-loader unpinIncompatibleMaps, so this PR's version of that change can be dropped.
• fix: Run the current egress datapath on existing VMs and pods #776 (landing next) adds ReattachEgress to Start. It moves every existing galactic_usid_egress filter onto the newly loaded program, and logs a failure instead of failing startup, since a fatal error there takes down the whole node's ingress datapath.

When you rebase, please swap the single-program replace in ReattachEgress for your two-program attach instead of adding a second re-attach pass. If you want a failed re-attach to stop startup, raise it on #776's follow-up so the two policies don't diverge.

Context: a datapath map change on 2026-10-07 blacked out every staging VM (#774).

[privateip]

One more overlap: #777 moves the attach-time map registration out of internal/cnibgp/bgp.go into a new internal/plumbing/ebpf/attachreg package, so this PR's change to attachUsidEgress will conflict on rebase. The function moves unchanged to attachreg/register.go, and the same edit applies there.

The move also means CNI ADD and the new startup repair pass share that code, so loading the service program in attachUsidEgress covers both. We plan to land #777 without waiting on this PR, so please build on it once it merges.