Carry every VM address on one NIC via a cloud-init network snippet

[v0l]

Closes #343. Stacked on #339 (feat/template-ip-resources-105) — merge that first, this rebases onto master after.

Every assignment now goes on the VM's single NIC through a per-VM cloud-init network config, so the address counts #105 sells are actually configured in the guest.

• make_network_config (lnvps_api/src/host/proxmox.rs:979) emits network-config v2 and returns None when the VM holds at most one address per family. Those VMs keep the existing ipconfig output byte-for-byte, so nothing already deployed is reconfigured.
• write_snippet / ensure_network_snippet / remove_network_snippet (:441) reuse the vendor-snippet mechanics but per VM (lnvps-net-{vm_id}.yaml), uploaded over SFTP rather than echoed through a shell — the content is multi-line YAML. cicustom composes vendor=…,network=….
• Wired into create_vm, configure_vm and the patch_firewall reconcile, so a VM whose assignments changed gets the file rewritten even when the volume ref compares equal. delete_vm removes the file after destroy, best-effort: a leaked snippet costs a few hundred bytes, while failing there would report a destroyed VM as still present.
• The interface is matched by MAC, not by name, so the config does not depend on guest device enumeration. One default route per family (first assignment's gateway wins, as ipconfig did). A SLAAC range contributes accept-ra: true rather than a pinned address.

The MAX_CONFIGURABLE_IPS cap and its admin/order guards are gone — the technical reason for them no longer exists, and the plan's own min/max remain the bound an operator sets. Defaults stay 1 everywhere, so no plan offers a choice until someone widens it.

Why one NIC rather than several: on the OVH-backed ranges the addresses share one router-issued vMAC ("use existing" in the Control Panel, confirmed by Kieran), and a second NIC would need a second vMAC. assign_mac already generates the vMAC once per VM.

Verification: cargo test --workspace --exclude lnvps_e2e green, ./scripts/run-e2e.sh 169 passed in 16.6s, clean clippy on every file touched. The lifecycle e2e orders a 2x IPv4 custom VM again and asserts both the template count and that the extra address is billed.

Not verified against a real hypervisor — there is no Proxmox in the e2e stack, so the generated config is covered by unit tests only. Before any plan is widened for customers, one VM on a live host (ideally on an OVH range) needs to confirm both addresses come up and traffic arrives on the second.

Originating channel: general.