[IMPROVEMENT]: Align release.yml trigger with Linux workflows (created → published)

[x15sr71]

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

• This PR adds new functionality.
• This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
• This PR is porting code from C to Rust.

Sanity check:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
• I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Repro instructions:

This PR has no runtime reproduction case — it only changes a GitHub Actions trigger.

---

What this PR does

Single line change in .github/workflows/release.yml:

-      - created
+      - published

Nothing else changes — no build steps, no job logic, no workflow names.

Background

release.yml has been triggering on release: created since it was first written in 2021. Every other packaging workflow — build_appimage, build_deb, build_deb_debian13, build_snap, build_linux_systemlibs, and build_mac — all use release: published, making release.yml the only remaining workflow that did not. This PR just brings it in line with the rest.

For the common case (non-draft releases)
No practical difference. GitHub fires both created and published at the same time for a directly-published release, so the workflow runs at the same moment either way.
publish_chocolatey.yml and publish_winget.yml are also unaffected — they trigger off the workflow name "Upload releases" via workflow_run and only care about whether it succeeded, not which event kicked it off.

For draft → publish flows (if used)
This is uncertain since the public release history doesn't tell whether drafts are part of the current process — but worth mentioning. With created, release.yml could run at draft-save time and upload Windows artifacts to a private draft release. If Chocolatey then tries to download the MSI from the public URL before the release is published, that would fail. With published, everything — Windows, Linux, and macOS — would build at the same moment when the release goes public. If drafts aren't part of the process here, this doesn't matter and the change is purely a consistency cleanup.

Happy to adjust or close if there's a reason created is preferred here.