Fixes for various Vultr API issues

[dboreham]

Summary

Fixes four open Vultr issues (#53, #55, #57, #61) which all stem from two Vultr-specific API behaviors that differ from DigitalOcean:

1. Vultr returns 0.0.0.0 as the initial IP for pending instances (DO returns empty/null). The create command treated "0.0.0.0" as a valid IP, skipping the wait-for-IP loop entirely. This caused DNS records to be created with 0.0.0.0.

2. Vultr rejects deletion of pending/locked instances with HTTP 500 (DO allows deleting in any state). Because the IP wait was skipped, the create command returned in ~2 seconds, and the test teardown tried to destroy the VM while it was still provisioning — silently failing every time.

Changes

• machine/subcommands/create.py: Treat "0.0.0.0" the same as None when checking the IP address, so the wait-for-IP loop runs correctly on Vultr.

• machine/providers/vultr.py: Retry destroy_vm with 5s backoff (up to 2 min) when Vultr returns transient 500 errors ("not currently active" or "currently locked").

• tests/test_e2e.py: Strengthen test_instance_has_ip to reject 0.0.0.0. Add teardown diagnostics so future destroy failures are visible in test output.

Test plan

• All 6 Vultr e2e tests pass (previously test_dns_record_created always failed)
• VM is fully cleaned up after test run (previously accumulated on every run)
• All 29 unit tests pass
• ruff check passes

Closes #53, closes #55, closes #57, closes #61

🤖 Generated with Claude Code

[dboreham]

The Claude Code session for this PR is here: https://codeassociates.github.io/conversations-with-claude/conversations/python-cli-tool/debug-fix-all-vultr-issues/index.html