Handle onboarding cancellation and deleted VM retries

[luke-lombardi]

Declining workload onboarding now prints Setup canceled. and exits successfully. Ctrl+C propagates as a normal cancellation, including at the credits checkpoint, instead of becoming an empty Error:.

Rerunning VM onboarding after its VM was deleted creates a fresh setup request. Interrupted creation keeps the original request and immutable launch body, so a lost response cannot create a duplicate VM. The retry is limited to one confirmed HTTP 410; authorization, conflicts, and other errors are preserved.

Validation: 598 SDK tests passed, 2 skipped; includes 36 onboarding cases covering cancellation, JSON output, deleted VM retries, lost responses, and permission failures. Ruff passed. Live staging checks passed: declining exits 0, Ctrl+C exits 1 without an empty error, and create/delete/rerun creates a distinct VM with the default 4 vCPU, 8 GiB, 50 GiB and no idle timeout. Both temporary VMs were removed.

[jackf-beamcloud]

Declining setup now exits 0 with "Setup canceled." (or one JSON result) and never touches compute. Ctrl+C is re-raised ahead of the RuntimeError catch, which matters because click.Abort subclasses RuntimeError. The deleted-VM path renews the request once on 410 only and keeps the stored creation body for lost responses. Tests cover all four setup kinds. Non-blocking: if the second 410 surfaces, the state file still holds that second request, so a rerun replays it, hits 410 again and renews. That works, it just costs a round trip. Python SDK CI is green; the Go and protobuf jobs were still pending when I looked.