Reserve fixed IPs on the lava network so Caddy can always start

lava was created by hand without an ip_range, so any container could be
given Caddy's fixed IP (172.20.0.5). After a reboot the containers race
for the low addresses and Caddy often fails with "Address already in use".

- The docker role now creates lava as 172.20.0.0/16 with dynamic
  addresses limited to 172.20.128.0/17, so 172.20.0.x is free for fixed
  IPs, and warns if the network still has the old layout.
- Gitea gets fixed IP 172.20.0.6 once the network has the reserved range,
  since its ufw-docker SSH rule points at its IP.
- ufw-docker allow rules for Caddy (80, 443) and Gitea SSH are managed by
  the playbook and follow IP changes.
- migrate-lava-network.yml recreates the existing network once: it takes
  down every compose project on lava (volumes kept), recreates the
  network, and brings them back up, Caddy first.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -112,6 +112,9 @@ Many services depend on Authentik for SSO. When deploying new services, consider
 - Network connectivity requirements within Docker stack
 - Hairpinning fixes for internal service-to-service communication
 
+### Shared Docker Network (`lava`)
+Created by the docker role as `{{ docker.subnet }}` with `ip_range: {{ docker.ip_range }}`. Docker only hands out dynamic addresses from that range, so `172.20.0.x` is reserved for fixed IPs: Caddy (`docker.hairpin_ip`, .5) and Gitea (`docker.gitea_ip`, .6). Both need fixed IPs because ufw-docker firewall rules point at container IPs. A network without the range (the 2024 original) is migrated once with `migrate-lava-network.yml`.
+
 ### Hairpinning Resolution
 Services inside Docker containers cannot reach external domains that resolve to the same server. Fix by adding `extra_hosts` mappings: