fix: trigger cloudinit volume replacement on content change only

[xnoto]

Summary

PR #7's replace_triggered_by = [libvirt_cloudinit_disk.commoninit] didn't actually fix cross-host applies. When the provider's local /tmp ISO is missing on the apply host (CI runner vs. laptop, post-reboot /tmp wipe), the disk's Read returns "not found", tofu drops it from state, and the next plan shows the disk as created (not replaced). replace_triggered_by does not fire on a create-following-drift, so the dependent libvirt_volume.cloudinit still planned an in-place url update and apply died on:

Error: Update Not Supported
  Storage volumes cannot be updated. All changes require replacement.

This change moves the trigger to the cloud-init content itself, captured in a terraform_data whose input is sha256 of the rendered meta_data + user_data + network_config. The volume now:

• ignore_changes = [create] — absorbs the volatile /tmp path drift entirely
• replace_triggered_by = [terraform_data.cloudinit_content] — replaces only when cloud-init content has actually changed

One-time upgrade churn

On first apply for any existing consumer, the new terraform_data resource is created. Because replace_triggered_by treats a create as a planned action, the existing libvirt_volume.cloudinit will be replaced once. That's a cdrom swap — harmless on running VMs (cloud-init only runs on first boot). After this one event, the volume is stable unless cloud-init content actually changes.

Test plan

• pre-commit (make test) green
• Downstream tfroot-libvirt plan no longer shows libvirt_volume.cloudinit ... will be updated in-place followed by an Update Not Supported error at apply
• Subsequent applies on a different host (CI runner vs. laptop) are no-ops for the cloudinit pair as long as content is unchanged

🤖 Generated with Claude Code