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

.github/workflows/pages.yml

@@ -4,14 +4,20 @@ name: Deploy web flasher
 # whenever there's a new binary to offer:
 #   - `release: released` fires when a release is published (a maintainer
 #     manually publishing a v1.0.0-style draft — see release.yml — or the
-#     first-ever creation of the dev-latest prerelease).
+#     first-ever creation of the dev-latest prerelease). By the time this
+#     fires, release.yml's own job (which built the draft) has long since
+#     finished, so its assets are already attached — safe.
 #   - `workflow_run` on Build catches every later dev-latest *update*: that
 #     release already exists after its first publish, so re-uploading
-#     assets to it is an edit, not a new "released" event.
-# Deliberately does NOT trigger on release.yml's own workflow_run — that
-# would expose a vX.Y.Z build's binaries through the flasher while the
-# release itself is still a draft, defeating the point of drafting it
-# (docs/ROADMAP.md: tagging is "a separate, deliberate step").
+#     assets to it is an edit, not a new "released" event. Also safe: Build
+#     uploads dev-latest's assets as a step within its own job, before the
+#     job (and so the whole workflow) completes, so this can't fire early.
+# Deliberately does NOT react to release.yml's workflow_run: a v1.0.5/v1.0.6
+# run once showed that racing an event against release.yml's own ~2-minute
+# asset-upload step (rather than something gated on it) fails with "no
+# assets to download" if this fires first. release.yml now dispatches this
+# workflow itself, via `needs:` on the job that uploads those assets, which
+# is ordered by construction instead of raced — see its dispatch-deploy job.
 on:
   release:
     types: [released]

.github/workflows/release.yml

@@ -139,3 +139,21 @@ jobs:
           draft: ${{ github.event_name != 'workflow_dispatch' }}
           body_path: ${{ github.event_name == 'push' && 'release-body.md' || '' }}
           generate_release_notes: false
+
+  # Runs once the job above has finished uploading this tag's assets --
+  # `needs:` orders that by construction, unlike pages.yml's old approach of
+  # reacting to this workflow's completion as an event, which could still
+  # arrive before the upload step actually finished. A draft release (the
+  # normal push-triggered case) is invisible to pages.yml's `gh release
+  # view` regardless, so dispatching here doesn't leak it early; it only
+  # ever surfaces a release once it's actually published, same as before.
+  dispatch-deploy:
+    needs: release
+    runs-on: ubuntu-latest
+    permissions:
+      actions: write
+    steps:
+      - name: Re-trigger the web flasher deploy now that assets are attached
+        run: gh workflow run pages.yml --ref main -R "$GITHUB_REPOSITORY"
+        env:
+          GH_TOKEN: ${{ github.token }}