Add mass deployment abort and mass instance orphan

[chrisghill]

Adds two new semi-destructive commands to mass and bumps the SDK to pick up the new Instances.Orphan method.

• mass deployment abort <deployment-id> — cancels a PENDING, APPROVED, or RUNNING deployment via mdClient.Deployments.Abort. A running deployment aborted mid-flight leaves any partial infrastructure changes in place.
• mass instance orphan <project>-<env>-<manifest> — break-glass operation that resets a stuck instance to INITIALIZED, clearing all Terraform/OpenTofu state locks via mdClient.Instances.Orphan. Active RUNNING/PENDING/APPROVED deployments are bulk-aborted server-side.

Both commands require the user to type the ID/name to confirm (matches instance destroy and resource-type delete). Both accept --force, -f to skip the prompt. instance orphan also accepts --delete-state to permanently delete remote state files; this triggers a stronger warning in the confirmation prompt since it's irreversible.

[chrisghill]

@claude review

[claude]

Claude finished @chrisghill's task in 2m 6s —— View job

---

Code Review

• Gather context and read changed files
• Review cmd/deployment.go changes
• Review cmd/instance.go changes
• Review documentation files
• Review go.mod/go.sum changes
• Compile findings and post review

---

Overall this is a clean, well-structured addition. Both commands follow the established confirmation pattern from runInstanceDeploy (destroy) and runResourceTypeDelete, and the SDK bump is straightforward. A few findings below, ordered by severity.

Findings

1. Pre-release SDK pseudo-version in go.mod

go.mod:18 pins to a commit pseudo-version (v0.2.1-0.20260515043345-6ce3d1195ebf) rather than a stable tag. This works fine but means the module can't be found via the proxy's versioned path and silently bypasses immutability guarantees. Track a tagged release as a follow-up once the SDK cut lands.

2. Success message shows UUID instead of the name the user typed

cmd/instance.go:396-397 — the orphan success output is:

fmt.Printf("✅ Instance `%s` orphaned (status: %s)\n", orphaned.ID, orphaned.Status)
fmt.Printf("🔗 %s\n", mdClient.URLs.Helper(ctx).InstanceURL(orphaned.ID))

The user invoked mass instance orphan api-prod-db but sees a UUID in the confirmation line, while the destroy flow at cmd/instance.go:287-288 prints the name the user typed:

fmt.Printf("✅ Instance `%s` decommission started\n", name)
fmt.Printf("🔗 %s\n", mdClient.URLs.Helper(ctx).InstanceURL(name))

runInstanceVersion (existing code, line 351) also uses updatedInstance.ID, so the orphan command is internally consistent with that pattern, but the inconsistency with destroy is a UX rough edge. Worth harmonising to one approach.

Fix this →

3. cmd.SilenceUsage = true placed before confirmation prompt

In runDeploymentAbort (cmd/deployment.go:207) and runInstanceOrphan (cmd/instance.go:369), SilenceUsage is set before the interactive confirmation block. The existing runInstanceDeploy sets it after the confirmation. Both are functionally equivalent here (the only early exit in the confirmation block is return nil, not an error), but it's a style inconsistency worth aligning for readability.

4. No signal-context propagation in runDeploymentAbort

cmd/deployment.go:199 creates a plain context.Background(). Other deployment commands that make longer API calls use signalContext(parent) (defined at line 197) for graceful SIGINT. An abort call is short-lived, so the practical risk is low, but it's inconsistent with the rest of the deployment command set.

5. Duplicate doc content in generated markdown (expected / cosmetic)

docs/generated/mass_deployment_abort.md and docs/generated/mass_instance_orphan.md each contain two Example sections — one embedded from the helpdoc markdown and one appended by the cobra generator. This is the same pattern in existing generated docs like mass_deployment_get.md, so it's intentional and not a new issue.

---

Summary

No blocking issues. Items 2–4 are low-severity and could be addressed in a follow-up or squashed into this PR before merge. The confirmation UX, warning text, and --delete-state flag are well-thought-out for a break-glass operation.