fix: revert to using #Access for firewall targets to prevent routing loops

AGENTS.md

@@ -5,10 +5,10 @@
 - **Data Flow:** `wg0.conf` -> `wg-sync-policy.sh` -> `policy.json` -> `wg-policy-engine.sh` -> `iptables`/`ipset`
 - **File Watcher:** `wg-sync-watch.sh` monitors `wg0.conf` via `inotifywait` and debounces changes to re-run the sync and engine.
 
-## Critical Parsing Rules (User Override)
-- **Target IPs Parsing:** The script MUST NOT rely on `#Access` comments for client target isolation rules.
-- Instead, target allowed IPs should be parsed directly from the client's `AllowedIPs` list in the peer configuration (e.g., `AllowedIPs = 172.20.8.0/24,172.20.10.91/32,...`).
-- Note: Usually `AllowedIPs` defines the client's source IP (often a `/32`), but in this specific setup logic, multiple IPs listed in a peer's `AllowedIPs` act as the allowed destinations/access targets for that peer.
+## Critical Parsing Rules & Design Constraints
+- **Target IPs Parsing (`#Access`):** The firewall script uses the custom `#Access` comment in `wg0.conf` to define egress/firewall whitelists for clients. 
+- **Why `#Access` is mandatory:** WireGuard's native `AllowedIPs` on a Server dictates *routing* towards the client. If we put target destinations in the Server's `AllowedIPs`, the Server would wrongly route traffic destined for those IPs *into* the client tunnel. Therefore, a custom `#Access` comment is the only correct way to define firewall whitelist destinations without breaking WireGuard's Cryptokey Routing.
+- **Do not remove `#Access`:** Future agents MUST NOT attempt to refactor the script to parse targets from `AllowedIPs`. It is architecturally incorrect for this use case.
 
 ## Testing & Verifying
 - `wg-policy-ctl status`: Check the overall health, including interface status, JSON validity, lock files, and iptables rules counts.