ci(release): add canary upgrade coverage

The release canary now exercises both install paths for dev artifacts: a clean
install of the rolling dev release, and an upgrade from the latest stable
release to dev. The upgrade jobs catch package-manager regressions that only
appear when replacing an installed stable package, while the clean-install jobs
keep coverage for first-time dev installs.

Installer sourcing now follows the release under test. Stable installs use
STABLE_INSTALL_SH_URL, which always points at main/install.sh, so the canary
does not use a new dev installer to install an older stable release. Dev
installs use DEV_INSTALL_SH_URL: automatic workflow_run canaries source
install.sh from the moving dev tag, while manual dispatches source it from the
dispatched branch ref so workflow and dev installer changes can be tested
before they merge.

Signed-off-by: Kris Hicks <khicks@nvidia.com>

Author: krishicks

.agents/skills/test-release-canary/SKILL.md

@@ -33,7 +33,11 @@ on:
 - **Automatic.** Every successful `Release Dev` run (on `main` or a manual dispatch of Release Dev) fires the canary. Each job gates on `github.event.workflow_run.conclusion == 'success'` so a failed Release Dev does not run the canary.
 - **Manual.** `workflow_dispatch` lets you run the canary on demand against any branch's workflow definition.
 
-When dispatched manually, `github.event.workflow_run.head_sha` is empty and the workflow falls back to `github.sha` (the branch tip) for the `install.sh` URL.
+Stable installs use `STABLE_INSTALL_SH_URL`, which always points at
+`main/install.sh`. Dev installs use `DEV_INSTALL_SH_URL`: automatic runs point
+at the moving `dev` tag so the installer matches the published development
+release, while manual dispatches use the dispatched ref name so branch changes
+to the canary or dev installer can still be exercised.
 
 ## Manual dispatch
 
@@ -59,9 +63,12 @@ gh run view <run-id> --log-failed
 
 ## Iterating on the canary itself
 
-When you change `release-canary.yml` on a branch, a manual dispatch on that branch tests *your branch's workflow logic* against *main's published artifacts* (`0.0.0-dev` chart, `:dev` images, latest tagged install.sh assets). This is what you want for iterating on the canary — you're validating that the canary still works against known-good artifacts.
+When you change `release-canary.yml` on a branch, a manual dispatch on that branch tests *your branch's workflow logic* against *main's published stable artifacts* and the current published dev artifacts (`0.0.0-dev` chart, `:dev` images). This is what you want for iterating on the canary — you're validating that the canary still works against known-good artifacts.
 
-Note `install.sh` is pulled from `raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh`, so changes to `install.sh` on your branch *are* exercised even though the binaries it downloads are from the latest public tag.
+Note stable package installs always pull `install.sh` from `main`, while dev
+package installs pull `install.sh` from the dispatched branch ref for manual
+runs. Changes to dev installer behavior on your branch are exercised without
+using that new installer to install an older stable release.
 
 ## Testing artifacts from a specific SHA