ci(release): upload into an existing release instead of creating a second one

[u9g]

v2.18.7 shipped with no assets, and get.livekit.io/cli 404'd from 2026-09-15 20:30 UTC until v2.18.7 was re-released by hand.

The release was created from the GitHub UI, which creates the tag at publish time — so by the time the Release workflow ran, a published release already existed for the tag. gh release create does not attach to an existing release: it created a second, untagged one (untagged-26db48ab9a2d552b0c27, see https://github.com/livekit/livekit-cli/actions/runs/35020034514/job/104554235237) with all 7 archives, and exited 0. That draft was later deleted.

goreleaser looked the release up by tag first and uploaded into it, so it tolerated this. The gh rewrite in #961 lost that property, silently. Every release before v2.18.7 had its tag pushed by git, so the workflow was always the first to touch the release and the gap never showed.

This restores it: if a release already exists for the tag, upload into it; otherwise create the draft as before. The draft stays, so release notes and attached binaries are still reviewed by a human before publishing.

One gap this does not close: when the release is published from the UI, releases/latest points at a release with no assets for the couple of minutes the build takes. Pushing the tag with git and publishing the draft CI produces avoids that window entirely.

Homebrew and Docker were unaffected because neither reads GitHub release assets.