fix(ui): make firewall settings consistent and gate device management

docs/firewall-tunnel-followup-20261008.md

@@ -0,0 +1,35 @@
+# Firewall and tunnel follow-up — 8 October 2026
+
+Status: source prepared in isolation; not deployed or accepted on a live node.
+Task 18 remains open for full firewall rule management, persistence and rollback.
+
+The Network entry uses a right-aligned status and the standard black glass-button.
+The settings page fills the dashboard content width. The dashboard background
+resolver now inherits the Network image for its detail routes instead of selecting
+the Web5 image; the explicit federation background is preserved. Copy distinguishes
+actual device tunnels, mesh connections, router settings and merely saved port
+entries. A running mesh no longer produces a false Protected firewall label.
+
+The new device section uses existing WireGuard APIs for add, reveal/copy and remove.
+Mutation controls require the new backend's explicit peer_management_verified flag;
+older or unavailable backends cannot enable them. Private configuration is fetched
+only by an explicit reveal action, QR SVG is sanitized, and cached navigation clears
+private details and rejects late replies. Failed creation/removal requires a fresh
+list before retrying. Pending/revoking operations get recovery guidance.
+
+Read-only operator-node checks confirmed an existing device tunnel and active mesh.
+The separate router store had no connection or forwarding entries. This does not
+contradict the separately retained manual firewall/mining repair. No live VPN,
+firewall, router, app or payment change was performed during these checks.
+
+Backend audit found that existing router add/remove-forward methods only write
+local JSON. They are not exposed as controls that claim to open or close real ports.
+The existing OpenWrt management screen remains linked. Actual node firewall rule
+inspection/editing and the complete app exposure workflow are still separate work.
+
+Validation checkpoint: 21 focused UI tests passed before the final background
+resolver and pending-operation display additions. Those additions, the complete
+app typecheck, responsive rendered-route/background checks and production build
+remain queued behind IndeeHub recovery qualification. No live acceptance is claimed.
+The backend peer-safety changes are isolated separately and also require tests and
+paired helper deployment before these new mutation controls can be enabled.

docs/post-1.9.0-work-backlog.md

@@ -516,6 +516,20 @@ remain open. See `docs/https-app-gate-followup-20261006.md`.
 
 ## 18. Firewall and tunnel UI/settings
 
+Operator refinements on 8 October, retained as acceptance requirements:
+
+- Keep status values aligned to the right edge with the other rows. Do not
+  present the mesh service as proof that the node firewall is protected.
+- Fill the main content width and inherit the Network tab background; opening
+  Firewalls & tunnels must not switch to a different page background.
+- Use the standard black primary button at the bottom of the Local Network
+  container, matching other container actions.
+- Use plain language throughout and provide real, supported configuration
+  management. Recognize existing connections; a missing saved router entry is
+  not proof that the node's tunnels or manually repaired firewall are absent.
+- Verify changes against the actual saved configuration. Controls must not
+  claim to apply firewall rules when a backend only writes a local entry.
+
 Status: in progress. The central read-only Firewall & tunnels screen, local
 network entry points, independent status/error handling and responsive route
 tests are implemented (ef6c10f0, 3f96be2c). Scoped configuration, persistence,