docs: document Proxmox write permissions and firewall apply scope, add live apply implementation with rule resolution and provider integration

Add minimum write privileges section covering VM.Audit and VM.Config.Network requirements for firewall orchestration, document NexaFabric comment marker approach for safe rule replacement, clarify that only VM/LXC-level rules with concrete workload targets are supported for live apply while security groups remain preview-only, add firewall interface checkbox requirement for enforcement, document

README.md

@@ -72,7 +72,14 @@ Minimum practical read privileges:
 - `VM.Audit` for VM and container inventory/config visibility.
 - `SDN.Audit` if you use Proxmox SDN zones, VNets, EVPN, or related network objects.
 
-For future write-enabled firewall orchestration, create a separate token or role and do not reuse the read-only token. Only enable write mode after previews and audit logging have been verified in your environment.
+For write-enabled firewall orchestration, create a separate token or role and do not reuse the read-only token. Only enable write mode after previews and audit logging have been verified in your environment.
+
+Minimum practical write privileges for VM/LXC-level firewall rules:
+
+- `VM.Audit` so NexaFabric can resolve guests and inspect existing rules.
+- `VM.Config.Network` on `/vms` or on the narrow VM/LXC paths you want NexaFabric to manage.
+
+NexaFabric writes only rules that carry a `NexaFabric policy=...` comment marker. During apply it removes and replaces its own marked rules for the selected policy, leaving manually created Proxmox firewall rules untouched.
 
 ### 3. Enable QEMU Guest Agent For VM IP Discovery
 
@@ -123,11 +130,20 @@ NexaFabric policy preview does not require Proxmox firewall writes. It compiles
 Before enabling real firewall apply workflows:
 
 - Ensure Proxmox firewall is enabled intentionally at the Datacenter, node, and guest level where you want enforcement.
+- Ensure the firewall checkbox is enabled on the relevant VM/LXC network interfaces, otherwise Proxmox may store rules without enforcing them for that interface.
 - Keep NexaFabric clusters in `read_only` mode until previews are reviewed.
 - Use `audit` mode policies first to see what would be allowed or blocked.
 - Confirm that Proxmox API token permissions match the exact write operations you plan to allow.
 - Keep backups of Proxmox firewall configuration before enabling automation.
 
+Live apply currently supports VM/LXC-level rules where the enforcement side is a concrete workload:
+
+- `ingress` policies apply to the destination VM/LXC.
+- `egress` policies apply to the source VM/LXC.
+- The opposite side can be `any`, an IP/CIDR, or another workload with an assigned IP in IPAM.
+- Security group and network-wide targets remain preview-only until they can be expanded safely.
+- `audit` mode does not write blocking Proxmox rules; it records the intended result without enforcement.
+
 NexaFabric is designed to read first, simulate second, and only apply after explicit confirmation.
 
 ### 7. Network Flow Visibility
@@ -178,4 +194,4 @@ nginx/         Reverse proxy example
 
 ## Safety Model
 
-NexaFabric never applies firewall changes without a preview, validation, and audit record. The included Proxmox provider is designed around read-only inventory first. Write-enabled orchestration is intentionally routed through explicit dry-run and apply workflows.
+NexaFabric never applies firewall changes without a preview, validation, and audit record. The included Proxmox provider is designed around read-only inventory first, then explicit dry-run and apply workflows for concrete VM/LXC firewall rules.