Epic TS_0 — Host network firewall (node-agnostic, cluster-install owned)

Design: [v4 design](https://github.com/automa-saga/traffic-shaper/blob/main/docs/bn-qos-multiclass-priority-design-v4-nft-priority.md) §8.4.1, §8.2, §8.3.3.

Own the **node-level host firewall** (`inet host` nftables table: SSH/mgmt allowlist, ICMP policy, in-cluster host-service ports), applied by the **node-type workflow that actually needs it** — currently `block node install`/`reconfigure`/`upgrade`, extending to `consensus node` when that workflow exists.

**Why this is a separate epic.** The host firewall protects the bare-metal host itself; it is a distinct concern from the per-workload `inet weaver` classification/shaping plane (owned by `block node install` + the daemon — TS_1/TS_2/TS_3), even though both currently live in the block-node workflow. Two tables, opposite lifecycles: `inet host` is set once and rarely changes; `inet weaver` churns continuously (the daemon rewrites set elements every ~5 s). Keeping them apart means daemon writes can never collide with the host's SSH/mgmt protection.

**Ownership correction (post-#802 review).** The original scope below wired `network firewall create` into the generic `kube cluster install` → `NodeSetupWorkflow` → `systemSetupWorkflow()` path, reasoning that since `systemSetupWorkflow()` already installs nftables + its systemd unit for every node type, the `inet host` table belonged there too. This turned out to be **too invasive**: `kube cluster install` is a general-purpose cluster-provisioning tool used for varying deployments, and unconditionally applying node-specific firewall rules on every generic cluster install doesn't fit that use case. The design doc itself was inconsistent on this point — §8.2 already showed `network firewall create` invoked directly from the block-node install sequence, while §8.3.1 attributed the `inet host` file to `kube cluster install`. The corrected design (matching §8.2, now implemented in #802) wires the firewall into the **block-node workflow** instead: `block node install` applies it (regardless of whether it bootstraps bare metal or deploys onto an existing cluster — nftables is guaranteed already installed in both cases), and `block node reconfigure`/`upgrade` can retrofit it onto hosts that predate this feature (#805, opt-in so routine reconfigures/upgrades don't unconditionally prompt for it). `kube cluster install` itself no longer touches the firewall.

The `network firewall` **command** itself stays a generic primitive in TS_1 (#757); this epic owns **orchestrating** it from the block-node (and future consensus-node) workflow, the mgmt-CIDR config surface, and host-side reboot persistence.

**Scope:**
- Wire `network firewall create` into `block node install` (and `reconfigure`/`upgrade` for retrofit).
- `--mgmt-cidrs` / `--ssh-port` / `--pod-cidr` / `--in-cluster-ports` / `--firewall-enabled` flags + profile-driven defaults (host-level config); day-2 changes via `network firewall add/remove --mgmt-cidr`.
- `inet host` reboot persistence: render `/etc/solo-provisioner/network-host.nft` + the `solo-provisioner-network-nft.service` oneshot (shared with TS_2, which renders `network-weaver.nft`).

**Decision (planning Q&A):** keep two nft tables (`inet host` + `inet weaver`); the workload table keeps the name `inet weaver` (the product name — consensus/mirror render their own rules into the same table; only the content differs).

Consumes the `network firewall` command (TS_1 #757). Hard prerequisite for SSH/mgmt access on every node running the block-node (or future consensus-node) workflow.