Re-cut v3.8.0: Velopack upload hardening (#3521) to main

[erikdarlingdata]

What

Bring the Velopack upload hardening (#3521) to main so it sits on the commit the re-cut v3.8.0 release build checks out.

Context

v3.8.0's first release build failed at the Velopack upload step — vpk's Octokit uploader dies mid-transfer on the large .nupkg and isn't idempotent, so the signed auto-update feed never published and that release was deleted. #3521 replaces vpk upload github --merge with gh release upload (robust + --clobber-idempotent). This PR carries that fix to main; then the v3.8.0 tag moves onto this merge and the release is re-published to re-fire the build with the working uploader.

No version change. This is a re-cut of the same 3.8.0, not a new version — Directory.Build.props stays 3.8.0. The merge itself only runs build + tests; every sign/velopack/upload step is gated on the release: published event, so nothing releases on the merge.

Field-validation delta

The 3.8.0 Azure/RDS field validation already ran; dev is one commit ahead of that sha, and the delta is exactly this CI-only build.yml change. It touches no collector/runtime code, so it cannot affect cloud collector behavior — delta explicitly accepted.

Single commit:

• b4a89a3b Upload Velopack channel feeds with gh, not vpk's failing Octokit uploader (Release build: persist SIGNED Velopack artifacts so a failed vpk upload retries without re-signing #3520) (Upload Velopack channel feeds with gh, not vpk's failing Octokit uploader #3521)

🤖 Generated with Claude Code

https://claude.ai/code/session_01RzwoqcD62jKyp6tzsWpZLz

[claude]

Reviewed. This is a clean, CI-only port of the already-fixed Velopack upload workflow change (#3521) from dev to main ahead of the v3.8.0 re-cut. No T-SQL or collector code is touched, so Lite/Darling parity isn't at risk here — and both Velopack channels (Lite, Darling Viewer) get identical treatment in this diff.

Checked the new PowerShell filter logic in both upload steps (nupkg / -Setup.exe / -Portable.zip / releases.<channel>.json) — it correctly selects the artifacts described in the comments and correctly excludes the inert assets.<channel>.json/RELEASES-<channel> files.

Non-blocking note: both new steps interpolate ${{ github.event.release.tag_name }} directly into the run: script (a value controlled by whoever creates the GitHub release). This is a known GitHub Actions script-injection footgun in general, but it's not new risk from this PR — the same pattern already exists at lines 743 and 1105 of this file, and release creation is already gated to users with write access. Just flagging for awareness in case a future cleanup wants to route it through an env: var instead.

[claude]

LGTM — reviewed the CI-only Velopack upload fix port to main; correct filter logic, both channels handled identically, no Lite/Darling parity or T-SQL surface touched.