iptables viewer displays a wrong snapshot path and a self-contradicting required-role; route comment also says super-admin but code allows role 4

Area: Admin deep-dive (trust/safety) (audit p15a) · Surface: /admin/iptables (AdminIptablesController), templates/admin/iptables/index.php, src/routes.php · Dimension: law-11-verify / law-12-correctness · Severity: minor

Beyond leaking infra, the leaked details are also factually wrong and internally contradictory: the shown snapshot path differs from the actual read path, the page claims it needs role 5 while role-4 tenant admins are looking at it, and the route comment claims super-admin-only. If the panel survives (it shouldn't, per the Law 6 finding), this is misleading documentation shown to a customer; either way it signals the surface wasn't verified against the running code.

Evidence

Controller reads from `private const SNAPSHOT_PATH = '/var/lib/mobieus/iptables-snapshot.json';` (AdminIptablesController.php:41) but the page prints `/tmp/iptables-snapshot.json` (iptables/index.php:568) — the displayed path does not match what the code reads. iptables/index.php:588 states `Required role: Platform admin (role 5)` while the action that served the page uses `requireRole(4)` (AdminIptablesController.php:51). routes.php:1892 comment says `(super-admin only)` and also cites `/tmp/iptables-snapshot.json`, but the bound handler enforces role 4.

Suggested fix. Once the Operations-reference panel is removed this resolves itself. If any of it is kept internally, correct the path to /var/lib/mobieus/iptables-snapshot.json and reconcile the role: either tighten index() to requireRole(5) to match the comment + panel text, or update the comment/text to role 4 — pick one and make all three agree.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.