docs+refactor(cni): fix stale package doc, promote hostconf/crdnames/nadpatch

[privateip]

Follow-up to mattdjenkinson's review on #303 — 2 of the review's 5 points. The other 3 are handled separately:

• The isTapMode()/CNI_NETNS_OVERRIDE dead-code point was already resolved upstream in this stack (725ef87, this branch's own parent).
• The missing nil-tracker.k8s guard point is now moot — the BGP publish call it was about no longer lives in ops_add.go at all (moved to its own galactic-bgp chain plugin in e33092c).
• The internal/cnitap vs internal/cni duplication point is a separate, larger follow-up: #(fix/cni-review-followups-dedup), stacked on top of this branch.

I'll leave a comment on #303 summarizing all 5.

This PR

internal/cni/doc.go staleness. The package doc still said ADD creates "a veth or tap interface" and listed tap as one of this package's subpackages — both stale since step 0 of this stack made galactic-cni veth-only and moved tap to galactic-tap-cni/internal/cnitap. Rewrote the doc to describe what internal/cni actually does now (VRF + veth pair + NAD patch only) and to explain why internal/cni/ipam, internal/cni/route, and internal/cni/tap are still physically nested there despite no longer being used by this package itself.

Package placement inconsistency. hostconf, crdnames, and nadpatch were nested under internal/cni/* while cnibgp/cniipam/cnitap/cniroute — doing the same cross-binary-sharing job — got promoted to top-level internal/*. That made it look like internal/cnitap (and cnibgp/cniroute) were reaching into cni's own internals, which is exactly what extracting them in the first place was meant to avoid. Promoted all three to internal/hostconf, internal/crdnames, internal/nadpatch. Package names are unchanged — every call site is a mechanical import-path update (15 files) plus two doc references (ARCHITECTURE.md, a comment in internal/cniroute/config.go).

internal/cni/ipam, internal/cni/route, and internal/cni/tap are a different category (kernel-primitive packages, like veth) and weren't part of this review point, so they're untouched.

Verification

• task lint ✅
• task build ✅ (all 8 binaries)
• go vet ./... ✅
• task test:unit ✅ (33/33 packages passing)
• task test:e2e not run (same caveat as every step in this stack — needs a Kind cluster bring-up not attempted here)

🤖 Generated with Claude Code

[fr6nco]

lgtm;

mostly just package reorganization as per PR description.

The base branch was changed.

[ecv]

Approving. The placement argument is right — cnitap importing internal/cni/hostconf read as reaching into another plugin's tree, which is the thing the extraction was supposed to end. Package names unchanged keeps it a pure import-path change, and the rebase carried RejectMovedIPAMKeys through the move intact.

The doc rewrite is more useful than the usual staleness fix, because it explains why ipam, route and tap are still nested rather than pretending they aren't.

One gap, filed rather than blocking: #344. internal/cni/hostgw is the same shape as the three you moved — imported by internal/cnitap and internal/cnibgp as well as by internal/cni itself — and it stayed behind. It's arguably the strongest case of the set, since it configures kernel state and its path claims an ownership that isn't true. doc.go doesn't mention it in either category either.

Nit: docs/plans/854-vpc-http-ingress-endpointslice.md still names internal/cni/crdnames and internal/cni/nadpatch. Plan docs are point-in-time, so ignore if that's the convention here.

CI green including E2E.