Severity: Info
File: .github/actions/setup-dotnet/action.yml lines 49–51

Description:
The composite action invokes the Microsoft dotnet-install.ps1 with -Channel:

inputs:
  version:
    description: '.NET version to install'
    required: true
    default: '10.0'
...
run: |
    powershell -ExecutionPolicy Bypass -File ./dotnet-install.ps1 `
      -Channel "$env:DOTNET_VERSION" `
      -InstallDir $installDir

-Channel "10.0" installs the latest patch in the 10.0 line at the moment the workflow runs. This gives you free security updates — but it also means:

• A green CI run on Monday and a red CI run on Tuesday can differ only because 10.0.x+1 shipped with a breaking change in the SDK.
• Release artifacts are not reproducible from a commit SHA alone; you also need to know which 10.0.x was installed at build time.
• An incident-response question like "does this 6-month-old binary have the CVE-2026-XXXX SDK fix?" cannot be answered from the repo.

The pattern is also inconsistent with the hardening already applied elsewhere in the repo (third-party actions pinned to SHAs, as #607 pushes for).

Suggested fix:
Switch the default to a pinned -Version, and let consumers opt into -Channel explicitly if they want floating patches:

inputs:
  version:
    description: '.NET SDK version to install (e.g. 10.0.7). Use -Channel for floating.'
    default: '10.0.7'     # bump via PR

Replace -Channel "$env:DOTNET_VERSION" with -Version "$env:DOTNET_VERSION" in the run: block. Add a dependabot-like audit (or a calendar reminder) to bump this version periodically so the repo stays current without drifting silently.