feat: toggle the enabled state of deployment targets

[NickJosevski]

Fixes #311

What changed

New commands — octopus deployment-target enable [<name> | <id>] and octopus deployment-target disable [<name> | <id>].

• Resolves the target with Machines.GetByIdentifier, flips IsDisabled, and saves via machines.Update.
• If the target is already in the requested state it prints a message and makes no update call.
• With no positional argument (and prompting enabled) it prompts for the target via selectors.Select over all targets, the same way deployment-target delete does. Under --no-prompt a missing identifier is an error.
• Shared logic lives in pkg/cmd/target/shared/disabledstate.go; enable/disable are thin cobra wrappers over it.

New create flag — --disabled on every deployment-target create command (azure-web-app, cloud-region, kubernetes, listening-tentacle, ssh), registered from a shared machinescommon.CreateTargetDisabledFlags and included in the generated automation command. It is flag-only: it deliberately does not add a prompt to the interactive create flow.

Test support — testutil.NewRootResource() now publishes the Machines link so command tests can exercise the machines endpoints.

Test evidence

New tests:

• pkg/cmd/target/enable/enable_test.go, pkg/cmd/target/disable/disable_test.go — end-to-end through the root command against the mock HTTP server, in the style of release/progression/prevent: named target, already-in-state short circuit, and the interactive prompt path. The PUT body is asserted to carry the flipped IsDisabled.
• pkg/cmd/target/shared/disabledstate_test.go — prompting behaviour (identifier supplied vs not, and the enable/disable wording).
• pkg/cmd/target/target_test.go — the enable/disable subcommands are registered and every target create command exposes --disabled.

Results from the worktree:

• go build ./... — clean.
• go test ./pkg/... — all packages pass, no failures. (gofmt/go vet report only pre-existing issues in files this PR does not touch.)

No live server is required by any of these tests.

Open questions / options

1. Dedicated enable/disable subcommands vs a general update command. The issue suggests "a new deployment target update command". I implemented the subcommands instead.

• Subcommands (chosen): small, discoverable surface; mirrors the existing octopus tenant enable|disable, so the CLI stays internally consistent; each command has exactly one effect, so --no-prompt automation is unambiguous.
• update --enabled/--disabled: extensible to name, roles, environments, tenants, machine policy, worker pool later — but a much larger surface to get right, and per-target-type (endpoint) fields would force either one giant command or five type-specific update commands mirroring create.
• Recommendation: ship the subcommands now. They are not mutually exclusive — a future deployment-target update can cover the remaining editable fields, and enable/disable would remain the ergonomic shortcut. Decision needed: is the team happy with this being the answer to Enhancement: Add support for toggling enabled state of deployment targets #311, or should the issue stay open for the broader update command?

2. Should workers get the same treatment? machines.Worker carries the same IsDisabled field and pkg/cmd/worker mirrors pkg/cmd/target closely, so octopus worker enable|disable plus --disabled on worker */create would be a near-identical change. I scoped this PR to deployment targets because that is what the issue asks for. Decision needed: do it in this PR, a follow-up, or not at all? (If yes, the shared helper would want to move from pkg/cmd/target/shared into pkg/machinescommon and be generalised over target/worker.)

3. Flag naming at creation time. I used --disabled (bool, default false).

• --disabled: matches the API field (IsDisabled) and the machine.IsDisabled model; a bare --disabled reads naturally and flag.GenerateAutomationCmd already emits bare bool flags correctly.
• --enabled=false: reads more positively but requires the =false form (cobra bools cannot take a separate value argument), which is awkward, and a default-true bool flag is easy to misread in help output.
• --disable: verb form, closer to the subcommand names, but inconsistent with the resource-state noun used elsewhere.
• Recommendation: keep --disabled. Decision needed: confirm, since renaming a shipped flag later is a breaking change.

4. Should deployment-target view/list surface the disabled state? Neither currently shows it, so after disabling a target there is no CLI way to confirm it other than the web UI. Adding it changes the table columns and the JSON shape, so I left it out of this PR. Worth a follow-up?

🤖 Generated with Claude Code