fix(ci): create release tags on main via merge_commit_sha

[seeones]

Background

The release tags v3.54.9 ~ v3.54.13 were all created outside main (on orphan commits), so tools like git describe and git branch --contains cannot associate them with main.

Root cause

marketplace-publish.yml resolves GIT_REF from the PR head.sha:

GIT_REF: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || 'main' }}

The workflow checks out that ref on pull_request: [closed] and runs git tag on its HEAD. When the PR is merged with squash, the commit referenced by head.sha never enters main's history (it becomes an orphan), so the tag is created on that orphan commit too.

Earlier PRs merged with a merge commit happened to make head.sha an ancestor of the merge commit, so the tags were "on main" by luck; switching to squash exposed the bug.

Note: the upstream RooCodeInc/Roo-Code workflow is identical, and its v3.54.0 tag is also an orphan — this is a defect inherited from upstream. Upstream's CLI cli-release.yml is correct because it uses gh release create (without --target, GitHub defaults the tag to the default branch HEAD).

Fix

1. Use merge_commit_sha for GIT_REF: it points at the commit on main for both merge and squash strategies, so checkout, git tag, and gh release create --target all land on main.
2. Harden the trigger: add github.event.pull_request.merged == true so a same-named but unmerged (closed only) PR cannot trigger a publish — otherwise merge_commit_sha is null, making GIT_REF empty and failing checkout.

Verification plan

After this PR is merged, on the next "Changeset version bump" PR merge, confirm the new vX.Y.Z tag is on main (git merge-base --is-ancestor <tag> main).