Feature: Add --priority to release deploy and runbook run

[HuyPhanNguyen]

Background

Task priority has been a server feature for a while, but there was no way to set it from the CLI. A customer asked about triggering priority deployments from automation they already had, and there was nothing to point them at.

Two gaps: release deploy and runbook run had no flag, and the SDK command struct had no field to put one in.

Results

Adds --priority to release deploy and runbook run. It behaves like --guided-failure: true, false or default.

Fixes HPY-1553

Depends on OctopusDeploy/go-octopusdeploy#460.

go.mod is pinned to a pseudo-version built from that branch (v2.115.1-0.20260819065856-b6f0f290712d), so CI compiles and exercises this change rather than sitting red on abstractCmd.Priority undefined. Swap it for the tagged release before this leaves draft — it must not merge on a pseudo-version.

Before

$ octopus release deploy --project X --version 1.0 --environment Dev --priority true
unknown flag: --priority

After

$ octopus release deploy --project X --version 1.0 --environment Dev --priority true
ServerTasks-41

Flag	Sent as	Server behaviour
--priority true	"priority": "On"	jumps the task queue
--priority false	"priority": "Off"	never prioritised, even on a priority lifecycle phase
--priority default	field omitted	server default
flag not given	field omitted	unchanged from today
anything else	no request sent	CLI errors before it calls the API

Priority also now appears in the Additional Options summary that interactive mode prints. It listed every other advanced option, so passing --priority read as though the flag had been ignored. There is still no prompt for it; the flag is aimed at automation, and adding a sixth advanced question for an Enterprise-gated setting seemed like the wrong trade.

Checked against a local server with the priority feature licensed. Deployments read back as On, Off and LifecycleDefault.

Two things worth knowing about the runbook side

default is the same as false for runbooks. RunbookRun.ChangePriority seeds Off and then collapses LifecycleDefault to Off, because runbooks have no lifecycle phase to defer to. Deployment.ChangePriority seeds LifecycleDefault and does not collapse. So the tri-state is only genuinely tri-state on release deploy. The flag help on runbook run says so.

Git-stored runbooks drop the priority server-side. CreateGitRunbookRunCommandV1Handler never copied Priority onto RunGitRunbookRun, so the value was accepted and discarded. Fixed in https://github.com/OctopusDeploy/OctopusDeploy/pull/46537. This is pre-existing and also affects the REST API and the MCP tool, but it does mean --priority on runbook run is only fully honoured against a server carrying that fix.

On licence and permission enforcement

An earlier version of this description claimed the server rejects the request when the licence or permission is missing, so the CLI needs no check of its own. That is true for release deploy only. PriorityTaskLicenseChecker has no runbook overload and TaskPriority.IsPriorityRunbookRun does no access check, so runbook runs skip both gates. The flag help no longer asserts a permission requirement it cannot keep, and I have raised the enforcement asymmetry separately rather than paper over it here.

Pre-requisites

• I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• I have considered informing or consulting the right people, according to the ownership map.
• I have considered the appropriate target version for this PR.
• I have considered appropriate testing for my change.
  • Automated testing / Exploratory testing / Nothing required?
• I have considered manually testing my changes on a branch instance to check correctness, stability and performance on Octopus Cloud.
• I have considered safety nets to reduce any time-to-recovery for my change.