release.yml/pages.yml: fix release-asset race with a needs:-gated deploy

[d3mocide]

Summary

Both the v1.0.5 and v1.0.6 releases hit the same "Deploy web flasher" (pages.yml) failure:

gh release download "v1.0.6" -R "$GITHUB_REPOSITORY" -D stable-assets --clobber
no assets to download
##[error]Process completed with exit code 1.

Root cause: publishing a release fires the release: released event immediately, but release.yml's own job — which builds the firmware and uploads that tag's four binaries — can still be running for another ~2 minutes. Whichever pages.yml run lands first tries gh release download <tag> before the assets exist and fails. This happened identically for both of the last two tagged releases, and left the live Pages site stuck serving stale v1.0.5 binaries even after v1.0.6 was fully built and published.

Fix (this revision): rather than reacting to another cross-workflow event (which just relocates the same race — an earlier commit on this branch tried adding workflow_run: ["Release"], which is still a race, just a narrower one), release.yml now gets a dispatch-deploy job gated with needs: release. That guarantees, by construction, that the re-dispatch of pages.yml only happens after the asset-upload step has completed — there's no window where the dispatched run can find the assets missing. This mirrors the build → assemble → deploy job-dependency pattern used by d3mocide/OpenMANET-XIAO-Gateway's build-firmware.yml, adapted to keep this repo's separate versioned-Release-as-distribution-artifact model (Launcher/SD-drop .bin downloads, the version.h↔tag check, the release-notes-exist gate) rather than replacing it outright.

A draft release (the normal tag-push flow) stays invisible to pages.yml's gh release view regardless of when dispatch-deploy runs, so this doesn't expose anything before a maintainer actually publishes it — same guarantee as before, just race-free instead of racy.

Also done in this session (no code change, recovery only): manually re-dispatched pages.yml on main once v1.0.6's assets existed — that redeploy succeeded and the live web flasher is now serving v1.0.6.

Test plan

• Validated both modified workflow files are well-formed YAML
• Manually re-ran Deploy web flasher (workflow_dispatch) to confirm assets exist and a fresh run succeeds — run 15, conclusion: success
• Build passes on this PR (release.yml's new job only runs on a tag push/dispatch, so it isn't exercised by PR CI)
• The next tagged release is the real end-to-end test of dispatch-deploy

🤖 Generated with Claude Code

https://claude.ai/code/session_01FHBCMHmvCZtH45K9CX8mF6