Spike 3.11 — Veth-elimination (SO_PRIORITY / ingress-controller) to de-risk netkit

**Epic:** #736 — BN traffic-shaper monitor

Design: [v4 design](https://github.com/automa-saga/traffic-shaper/blob/main/docs/bn-qos-multiclass-priority-design-v4-nft-priority.md) §6.5, §10 headline risk H1 / risk 17.

**Spike** (planning note 7). The entire ingress mechanism attaches HTB to the host-side veth (`lxc...`). Cilium is migrating veth → netkit; when that lands, the veth attach point and the `hostLegacyRouting` flip both become invalid simultaneously (headline risk H1). The veth lifecycle also forces a per-pod-restart unprioritised-ingress window (risk 3) and the stale-qdisc problem (#749). Investigate alternatives that remove the veth dependency.

**Goal:** assess feasibility and produce a recommendation; no production code.

**Investigate:**
- `SO_PRIORITY`-from-BN (§6.5): the BN process calls `setsockopt(SO_PRIORITY)` per connection (it already knows each connection's category). HTB classifies natively on priority, so the existing hierarchy is reused; the entire nft classification ruleset collapses to one socket option. Requires BN-team buy-in — frame the ask.
- An ingress-controller container running alongside the BN pod (can it own ingress shaping without depending on the host-side veth, and without interfering with the BN Helm chart?).
- IFB-on-NIC-ingress viability under Cilium tcx (§10 risk 17 notes it is invisible to classic tc filters on 1.16+).

**Output:** a written feasibility + recommendation comment, and any follow-up stories it warrants.

Fast-follow (de-risking; not MVP).

Read docs/bn-qos-multiclass-priority-design-v4-nft-priority.md, especially §§6.5 and 10, and review risks H1, 3, and 17. Investigate SO_PRIORITY from the BN, an ingress-controller container, and IFB-on-NIC ingress under Cilium tcx, including the BN-team ask. Done means a feasibility and recommendation comment plus any warranted follow-up stories.

Written by the indexing model from the issue text.