Merge branch 'master' into next

Forward-merge of 12 master commits past the previous merge
(823b830, master @ 18019bb): dep-audit bumps (rand,
clap, tun, rtnetlink, windows-service, plus the bump-safe
lockfile batch), bloom-storm chaos scenario, control-socket
resolver consolidation, gateway dns.listen default change,
OpenWrt ipk README refresh, gateway tutorial review, Ethernet
MTU rustdoc fix, dead session-variant drop, CHANGELOG prep.

Conflict resolution:

- CHANGELOG.md: both bullets kept under [Unreleased] / Fixed.
  Master's spanning-tree internal-path-propagation fix precedes
  next's tree-ancestry-test determinism entry and the
  responder-Disconnect XX-handshake entry.
- src/protocol/session.rs: kept next's SessionSetup/SessionAck
  variants and rustdoc. Master's drop of those variants suits
  v0.3.0's FSP phase-byte dispatch but is undone by next's
  v0.4.0 wire format, which retains the variants and uses the
  inner msg_type byte for handshake identification.
- src/transport/ethernet/mod.rs: kept next's "interface MTU - 4"
  comment. Master corrected the v0.3.0 3-byte rustdoc; next
  redesigned the framing to a 4-byte header (type/flags/length)
  for shared-media beacons, so master's correction does not
  apply to next's format.

Auto-merged cleanly: Cargo.toml (next's 0.4.0-dev + the new dep
pins from master), Cargo.lock, all gateway docs,
docs/reference/configuration.md, packaging files,
.github/workflows/ci.yml, testing/chaos/sim/* and
testing/ci-local.sh (bloom-storm additions), src/config/*.

Local verification: cargo build --release, cargo test (1252
passed, 4 ignored), cargo clippy -D warnings, cargo fmt --check
all green.

docs/design/fips-gateway.md

@@ -130,7 +130,7 @@ There is no `fipsctl gateway` subcommand; clients (including
             │                                   │
             │  ┌──────────────┐  ┌───────────┐  │
             │  │   DNS proxy  │  │  Virtual  │  │
-            │  │   ([::]:53)  │─▶│  IP pool  │  │
+            │  │ ([::1]:5353) │─▶│  IP pool  │  │
             │  │   .fips only │  │ (state    │  │
             │  └──────┬───────┘  │  machine) │  │
             │         │          └─────┬─────┘  │
@@ -182,13 +182,18 @@ involving the DNS proxy or the pool.
 ### DNS Resolution Flow
 
 1. A LAN client sends a DNS query to the gateway's listener (default
-   `[::]:53`, configurable via `gateway.dns.listen`).
+   `[::1]:5353`, configurable via `gateway.dns.listen`). The default
+   is loopback-only on an unprivileged port: the canonical deployment
+   has another resolver on the host (dnsmasq, systemd-resolved, BIND)
+   holding port 53 and forwarding `.fips` queries to the gateway over
+   loopback. Operators on a host without a pre-existing resolver on
+   53 can override the listen value to `"[::]:53"` to let LAN clients
+   query the gateway directly.
 2. If the question is not for a `.fips` domain, the gateway replies
    `REFUSED`. The proxy is intentionally narrow — it does not resolve
    public DNS, and the LAN's primary resolver should hold port 53 on
-   the gateway host (the OpenWrt init script wires this up by binding
-   the gateway listener to a non-conflicting port and configuring
-   dnsmasq to forward `.fips` queries there).
+   the gateway host (the OpenWrt init script wires dnsmasq to forward
+   `.fips` queries to the loopback listener automatically).
 3. The gateway forwards the query to the daemon resolver
    (`gateway.dns.upstream`, default `[::1]:5354`). The daemon must
    match: an IPv6 socket bound to `[::1]` does not accept v4-mapped