docs: explain virbr0 firewalld zone and WARP/SSH-only gotcha

[xnoto]

Summary

• Document why VM-originated traffic to host services on hero hits a different firewalld zone (libvirt, on virbr0) than LAN traffic (public, on enp7s0).
• Explain the practical symptom: WARP-routed traffic terminates in the k3s VM (the warp-connector cloudflared pod) and re-enters hero through virbr0. Only ports admitted by the libvirt zone get a SYN-ACK. SSH is in the default allowlist, so it "just works"; everything else is silently rejected. From the LAN the same destination port reaches public and works, which masks the asymmetry.
• Provide the firewall-cmd --zone=libvirt --add-port=... recipe and note that the dmacvicar/libvirt provider has no firewalld resource, so durable host-firewall config belongs in ansible-site-cluster.

Context

Hit this debugging hero:8080 over WARP — port 22 worked, every other port returned Network is unreachable. Cloudflare-side audit (Gateway rules, Access apps, infrastructure targets, split-tunnel) showed no port-22 gating anywhere. Packet capture on hero traced the SYNs to 192.168.122.0/24 arriving on virbr0, where the libvirt zone's default priority=32767 reject rich rule was silently dropping all but the allowlisted services. Fix on hero was a one-liner; this PR captures the gotcha so the next person doesn't burn the same hour.

Test plan

• Docs-only change — no apply needed.
• Confirm the recipe works against a fresh libvirt zone (already verified for 8080/tcp on hero).