[privateip]

Summary

Tenant taps stamped before host-only stamps recorded an owner still leak, because the stale tap reclaimer from #1331 only accepts a stamp that names an owner.

Those taps were kept by their own DEL for the same reason, so nothing removes them, and each one keeps a route and an unattributed traffic policy row.

The reclaimer now also accepts a host-only stamp with no owner. Every other guard stays in place, so a tap a VMM holds, or one a VPCAttachment or advertisement still names, is kept.

Test plan

• A detached tap with an owner-less host-only stamp is removed on the second pass, with its route and eBPF rows, on a real kernel
• The same tap is kept while a VMM holds it, or a VPCAttachment or advertisement names it
• After deploy, the leftover taps on the affected staging node are reclaimed and the unattributed policy counter there goes flat

Fixes #1330

[privateip]

Two independent reviews ran on this PR, plus one second pass after the review fixes. All returned merge.

• Correctness review: found no defect. It checked that removal with the empty owner only reaches taps whose owner-less stamp is unchanged under the VRF lock, and that a malformed stamp, a held tap, a live VPCAttachment and an advertisement each still keep the tap. It ran the stale tap unit tests and vet. It could not run the privileged kernel test, which the Unit Tests (root) job has since passed. The same test also passed locally as root against a real kernel.
• Conventions review: asked for comments to state the stamp contract instead of its history, plus wording nits. These are fixed in the two follow-up commits, and a second pass confirmed them.

CI is green on the head. Auto-merge is on with the merge method, behind the required code owner approval.

[ecv]

Approve.

Widening the candidate test to a well-formed host-only stamp with no owner leaves every keep guard intact, and none is skipped for the owner-less case.

• Guards are shared: detachedTenantTap (no fd on any queue), the advertisement prefix check, the VPCAttachment identity match and the two-pass confirmation all run on the same path for owner-less taps. The new keep-cases (VMM-held, live VPCAttachment, advertisement-named, malformed stamp) cover each.
• Mid-ADD: tap.Add runs inside vrf.EnsureAndEnslave, so the tap's brief unstamped moment is under the same lock, and an empty alias is never a candidate. The removal re-reads the link under the VRF lock and compares the full candidate (ifindex and alias); an adopting ADD rewrites the alias, so again != t keeps the tap.
• Deleting with the empty owner is safe: tap.OwnedBy accepts it only when AliasOwner(alias) is also empty, so a tap a new owner has claimed is left alone.
• API reads are live, not cached: the client is client.New (no informer cache). Any list error resets the pending set and removes nothing, and an empty set of identified attachments aborts the pass with errNoIdentifiedAttachments. Read failure keeps the tap.
• Owner-less stamps come from older builds whose ports-only alias recorded no owner, including an older build's ADD after a rollback; production HostOnlyAlias always passes the container ID. A live VM's tap stays safe through the guards above (VMM fd, an identified VPCAttachment, an advertisement), not through anything in the stamp, so only an orphan with none of them is reclaimed.

Follow-ups:

• A first-time deploy reclaims leftover owner-less taps from old builds on the second 5-minute tick. Check the galactic_cni_stale_taps_reclaimed_total jump in staging before the tag goes out.
• identifiedAttachments trusts that the node's client sees the same VPCAttachment set as the whole cluster. The non-empty guard only covers the all-missing case, so a partial view would still reclaim. Worth a note in the docs.