ci: release ordering, CodeQL gate and a release-readiness check

[serialexperimentslainnnn]

Summary

Four CI changes on the road to the 5.0.0 release. No plugin code is touched.

1. release.yml reordered to the intended sequence — merge to main → cut and sign the tag → open the GitHub Release → build and publish to the Marketplace **from that tag**. It previously
   built, published, and then stamped a tag on what had already gone out.
2. CodeQL required on develop, not only on main. Both jobs already ran on every PR into
   develop; requiring them only decides whether anyone has to look at the result.
3. A release-readiness gate: develop → main cannot merge while Claude or Dependabot has an
   open pull request into develop.
4. apply-rulesets.sh fixed — it stripped only the key named exactly _comment, so a second
   annotation in the same object reached the API and got a bare 422.

Type of change

• Docs / build / CI
• Bug fix

Risk and rollback

Risk: confined to CI and release. The plugin artifact is unchanged. The sharp edge is #3: it is
a required check, and a required check that never reports blocks a PR forever — so the ruleset
must be applied after this merges, never before (see the ordering note below).

Rollback: revert the commits and re-run scripts/apply-rulesets.sh. Nothing here has reached a
user; nothing is published.

Ordering — this matters

scripts/apply-rulesets.sh must run after this is merged into develop. The new required
check No bot PRs pending on develop does not exist as a job until then, and applying the ruleset
first would leave PR #35 waiting on a check nothing can ever report.

Notes for reviewers

Why #3 is a status check and not a ruleset rule. GitHub rulesets speak of checks, signatures
and approvals. They have no vocabulary for "no other pull request exists", so the gate has to be a
job, required by display name like every other one.

The Dependabot cost is real and is written into the workflow rather than left to be discovered.
Dependabot's resting state in this repository is "has something open", so draining that queue
becomes a release step. That is the intended trade — nothing ships alongside an unmerged dependency
bump — but it is the kind of gate people learn to bypass if the queue is ignored for weeks. If it
starts being routinely in the way, the answer is to merge Dependabot more often, not to widen the
filter.

On #1, two things a reviewer should push back on if they disagree:

• Cutting the tag before the build reverses a deliberate earlier decision, and the comment that
  argued for the old order was right at the time. What changed is that the whole publish job now
  sits behind the marketplace environment, so the tag cannot appear before a human approves. The
  residual case — a tag that outlives a failed publish — is real, and the asset upload carries
  --clobber so re-running is the recovery.
• It is deliberately not two workflows chained by the tag push. A tag pushed with the
  GITHUB_TOKEN does not create a workflow run (the recursion guard), so chaining would need a PAT,
  a GitHub App or a deploy key — a long-lived write credential — to buy an ordering that one run
  already achieves by checking the tag out.

Found during review of my own change, and NOT fixed here — flagged so it is a decision rather
than an oversight:

• release.yml, "Create and sign the release tag": the comment claims the step is a no-op when the
  tag already exists, so a failed publish can be recovered by re-running. It is not — git tag -s
  exits non-zero on an existing tag, and fetch-depth: 0 fetches tags, so the re-run aborts before
  reaching the --clobber upload. Needs an existence guard.
• release.yml header: the justification "main is a moving ref" is inaccurate. actions/checkout
  defaults to github.sha, so the run was already pinned to the triggering commit. Building from
  the tag is still right as a provenance statement; the stated reason is not.

Both were surfaced by a security review pass over this branch, which found no security findings
of its own — the changes keep every irreversible action behind the same approval boundary.

How was this tested?

• ./gradlew test (694, 0 failures) and npm test (84) — green before these commits; none of
  them touch plugin code.
• Workflow YAML parsed and every required check name in .github/rulesets/*.json cross-checked
  against an actual job display name — no orphans.
• The bot author matcher exercised against app/claude, app/dependabot, claude[bot],
  dependabot[bot] (all blocked) and serialexperimentslainnnn, claudia99 (both pass).
• release.yml end to end. It cannot be tested without publishing; the first real run is the
  5.0.0 release.