CLI release notes still say Skyhook, and their download URLs 404

[lockwobr]

Summary

The CLI release workflow builds nodewright_* archives but still publishes install instructions that say skyhook. The result is not merely stale wording: every download command in the published notes 404s, because the asset names it points at do not exist.

Part of the rename tracked in #310.

What's wrong

.github/workflows/cli-release.yaml renames nothing in the Create GitHub Release step:

• name: "Skyhook CLI ${{ ... }}" (line 133)
• Body heading ## Skyhook CLI ... (line 140)
• "The binary must be named kubectl-skyhook" / "used directly as skyhook" (lines 147-148)
• Download URLs pointing at github.com/NVIDIA/skyhook and asset skyhook_<version>_<os>_<arch>.tar.gz (lines 152, 157)
• sudo mv skyhook /usr/local/bin/kubectl-skyhook (lines 154, 159)
• kubectl skyhook version --client-only (line 165)

Meanwhile operator/Makefile cli-release-build (lines 491-521) already emits nodewright_$(CLI_VERSION)_<os>_<arch> archives containing a binary named nodewright. Confirmed on the published release:

$ gh release view cli/v0.3.0 --json assets --jq '.assets[].name'
checksums.txt
nodewright_v0.3.0_darwin_amd64.tar.gz
...
nodewright_v0.3.0_windows_arm64.zip

So the curl -LO .../skyhook_v0.3.0_linux_amd64.tar.gz line in the notes cannot succeed. The repo half of the URL redirects fine (NVIDIA/skyhook -> NVIDIA/nodewright); the filename half does not.

Impact

Anyone following the install snippet on a cli/* release gets a 404, then a tar failure on the HTML error body. This shipped in cli/v0.3.0, the first CLI release after the rename.

Already done

The cli/v0.3.0 release title and body were corrected by hand so the current release is usable. That is a one-time patch of published content; the workflow will regenerate the wrong text on the next cli/* tag.

Acceptance criteria

• Release name: and body heading say NodeWright CLI <version>
• Install prose says kubectl-nodewright / nodewright
• Download URLs use github.com/NVIDIA/nodewright and the nodewright_<version>_<os>_<arch> asset names the Makefile actually produces
• mv target and verify commands use kubectl-nodewright / kubectl nodewright
• Asset names in the workflow are derived from, or checked against, cli-release-build so the two cannot drift silently again
• Sweep the remaining kubectl-skyhook strings in .github/ (labels.yml component description, both issue forms' component dropdowns)