Unit 2 follow-up: R2.2 egress enforcement (relay-layer frame inspection) + R2.4 dynamic port-mapping #553

Split from #499 (Unit 2) per the design decision recorded there: the proved spike (docs/spikes/2026-06-21-gvproxy-attachment.md §5) established that gvproxy v0.8.9 has no per-client egress ACL API, and its management API is unix-socket-only / unreachable from a PTask — contradicting the 192.168.127.254:8080 HTTP assumption in the task body and architecture.md. Egress enforcement therefore cannot be "POST the rules to gvproxy"; it must be a relay-layer mechanism. This task owns that design.

Scope

• R2.2 — egress allowlist enforcement via relay-layer frame inspection: parse Ethernet/IP headers in the net::switch relay and drop frames whose destination falls outside the session's allow_subnets / allow_protocols. Owns the security-mechanism design (header-parse surface, drop-vs-reject semantics, performance, fail-closed default).
• R2.4 — dynamic port-mapping transport: define the correct control path (the management API is unix-socket-only, not the gateway IP), distinct from the static POST /services/forwarder/{expose,unexpose} path already landing in feat(minimald,minvmd): egress/ingress policy enforcement, VM-wide egress, and integration tests #499.
• Docs: correct architecture.md §"Unit 2" (the 192.168.127.254:8080 management-endpoint claim) to match the spike — unix-socket control surface; egress filtering at the relay.

Acceptance

• Egress frames outside allow_subnets/allow_protocols are dropped at the relay; fail-closed when a policy is set.
• R2.7 rate-limited tracing::warn! fires on real drops.
• Enforcement proofs (spike Proofs 1 & 2) ship as compiling #[ignore] netns tests under ci-netns.yml (privileged netns + pinned gvproxy + root), matching the feat(minimald): gvproxy DM2 child lifecycle, OwnIp switch attachment via SCM_RIGHTS, and integration tests #496/feat(minimald,sandbox2): wire net switch into live OwnIp launch path #547 precedent.
• architecture.md §Unit 2 no longer references the gateway-IP management endpoint.

References

• Split from feat(minimald,minvmd): egress/ingress policy enforcement, VM-wide egress, and integration tests #499; design rationale in its needs-human hand-off
• Spike docs/spikes/2026-06-21-gvproxy-attachment.md §5 (Action item 5: "File this as a design question for the Unit 2 task")
• Epic epic: minimald networking — PTask network modes, DNS, egress/ingress, WireGuard mesh #478

This is a security-control design; likely warrants /spec (or a spike) before execution rather than direct dispatch.