fix(ci): trigger the plugin release on workflow_run, fix the Windows upload, link bundles in the notes

[OpenSauce]

Three fixes to plugin-release.yml, all surfaced by v0.3.0 being the first release since #271 added the workflow.

1. The workflow never triggered

v0.3.0 published with no plugin bundles attached — there is no Plugin Release run in the Actions history for that tag.

It triggered on release: published. GitHub deliberately refuses to start workflows from events created with the default GITHUB_TOKEN, as a guard against recursive runs — and dist's host job creates the release with exactly that token. So the event that was supposed to drive this workflow can never fire it.

The original header comment was right that tag push races dist and 404s for the ~8 minutes dist spends building. That reasoning was sound; it just landed on a trigger that couldn't fire.

workflow_run avoids both: it fires when Release completes, so the release object exists, and head_branch carries the tag (verified against the real run: headBranch: v0.3.0). Guarded on a successful run from a tag push, since Release also runs on pull_request.

2. The Windows bundle failed to upload

Regression from #280, which added Windows to the matrix. The Windows job built and packaged correctly, then died on upload:

RELEASE_TAG: v0.3.0            # env var set correctly
shell: C:\Program Files\PowerShell\7\pwsh.EXE
gh release upload "$RELEASE_TAG" "Rustortion-windows-x86_64.zip" --clobber
release not found

No explicit shell meant pwsh, where $RELEASE_TAG is not an env var reference — it expanded to empty and gh was asked to upload to a release named "". shell: bash was added to the clean, verify and package steps but missed here.

Every run step that reads a shell variable now names its shell explicitly; audited the whole job. Package (Windows) legitimately stays on pwsh and uses $env:.

3. Release notes don't mention the plugin

dist writes the release body and only knows what it built, so its table lists the standalone alone. The plugin zips land in Assets with nothing pointing at them, reading as a standalone-only release.

A notes job appends a plugin download table with per-platform tested/untested status, keyed on an HTML comment marker so re-dispatching doesn't stack duplicates.

State of v0.3.0

Both Linux bundles are attached (uploaded by a manual dispatch). Windows is missing pending this fix — a re-dispatch after merge will attach it; --clobber makes re-uploading the Linux ones harmless.

Verification

The Windows shell fix and the notes job are provable on a re-dispatch. The workflow_run trigger is not — it only fires off a real tagged release, so its first genuine test is v0.4.0. Guard logic and tag extraction are verified against real event data; workflow_dispatch remains the fallback.

[Copilot]

Pull request overview

Updates the plugin bundle release automation so plugin artifacts reliably build and attach after cargo-dist finishes publishing a GitHub Release, and improves the published release notes to clearly link plugin downloads alongside the standalone artifacts.

Changes:

• Switch plugin-release.yml from release: published to a workflow_run trigger on the dist-generated Release workflow completion, with guards to only act on successful tag pushes.
• Update tag resolution to use workflow_run.head_branch (tag name) for automatic runs while keeping workflow_dispatch as a manual fallback.
• Append an idempotent plugin download table to the GitHub Release notes after bundle upload completes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.