Extend #7857's egress firewall to Kubernetes and systemd deployments

[JSONbored]

Problem

#7857 ships real, verified network-egress enforcement (dnsmasq + iptables/ipset, deny-by-default with the ratified allowlist) for the miner's Docker/Compose deployment path -- the primary, documented self-hosting option. k8s/miner-deployment.yaml (self-host on Kubernetes) and systemd/loopover-miner.service.example (bare-host) get no enforcement at all yet.

Deliberately split out rather than bundled into #7857: each deployment path needs a genuinely different privilege-setup mechanism, not a copy-paste of the Docker entrypoint.

Area

k8s/miner-deployment.yaml, systemd/loopover-miner.service.example, packages/loopover-miner/lib/egress-allowlist.ts + egress-firewall-config.ts (already product-agnostic across deployment paths -- reusable as-is).

Proposal

Kubernetes: k8s/miner-deployment.yaml's pod spec sets securityContext.runAsNonRoot: true at the pod level -- a hard, kubelet-enforced admission constraint, not just a Dockerfile default. A root-then-drop entrypoint (Docker's approach) is structurally impossible here. The idiomatic k8s pattern instead: an initContainer with NET_ADMIN/NET_RAW that runs the SAME generate-egress-firewall-config.js + applies the iptables/ipset ruleset, then exits -- containers within a pod share one network namespace by default, so rules an initContainer sets up persist for the main (non-root) container that starts after it. This is a well-established pattern (e.g. Istio's own istio-init container does exactly this for sidecar iptables setup) -- not novel.

systemd: no initContainer equivalent, but systemd has its own clean primitive: ExecStartPre=+/path/to/setup-script -- the + prefix runs that specific directive as root regardless of the unit's own User= directive. Add an ExecStartPre=+ calling the same config-generation + ruleset-apply flow, before the main ExecStart= (which keeps running as the unit's already-configured non-root User=).

Both should reuse egress-allowlist.ts/egress-firewall-config.ts verbatim (already pure, product-agnostic logic) -- only the privilege-setup mechanism differs per deployment path.

Deliverables

• Kubernetes: an initContainer in k8s/miner-deployment.yaml applying the egress firewall before the main container starts.
• systemd: an ExecStartPre=+ in systemd/loopover-miner.service.example doing the same.
• Tests/verification appropriate to each (the existing packages/loopover-miner/scripts/verify-egress-firewall.sh is Docker/Compose-specific -- a k8s equivalent likely needs a real cluster, e.g. kind/minikube in CI, or manual verification documented clearly if that's not feasible).
• DEPLOYMENT.md updated to remove the "not yet enforced on those paths" caveat Enforce AMS sandbox network-egress deny-by-default + allowlist (implements #7648) #7857 added.

Resources

• Enforce AMS sandbox network-egress deny-by-default + allowlist (implements #7648) #7857 (ships the mechanism + Docker/Compose enforcement -- read that PR first)
• Decide default network-egress policy for AMS sandboxed execution (deny/allowlist, not open) #7648 (the ratified default this implements)
• packages/loopover-miner/lib/egress-allowlist.ts, egress-firewall-config.ts (reusable as-is)
• packages/loopover-miner/Dockerfile, scripts/egress-firewall-entrypoint.sh (the Docker precedent to adapt, not copy verbatim)

Boundaries

maintainer-only -- security-critical sandbox enforcement, same posture as #7857 itself. Blocked by #7857.

[linear-code]

JSO-5728