fix: investigate preventing duplicate CI runs on release-please PRs

[DevSecNinja]

Summary

The chore(main): release vX.Y.Z PR opened by release-please triggers our CI (Lint, Pages) on the pull_request event, and then the same CI runs again on the push to main once the PR is merged. For release PRs this is effectively redundant work — the content was already validated by the CI that ran on the source commits before they landed on main, and Pages re-runs on the merge push anyway.

We should investigate whether we can avoid running the pipelines on the release-please PR itself (without losing required status checks needed for branch protection).

Background / current triggers

• .github/workflows/lint.yml → runs on pull_request and push: main.
• .github/workflows/pages.yml → runs on pull_request (opened/synchronize/reopened/closed) and push: main.
• .github/workflows/release-please.yml → runs on push: main, opens/updates the release PR.

So a release PR gets a full PR CI run, then a full main CI run after merge.

Things to investigate

• Confirm whether the double run is actually wasteful for release PRs, or whether the PR run is required for branch protection status checks.
  • Note: the release-please workflow comment mentions a dedicated GitHub App is used specifically so release PRs trigger required CI status checks under branch protection — so simply skipping CI may break merging. Verify before changing.
• Options to consider:
  • Skip/condition CI jobs on the release branch (release-please uses release-please--branches--main style head refs) via if: guards or branches-ignore on pull_request.
  • Use paths-ignore more aggressively for release PRs (they typically only touch package.json + CHANGELOG.md).
  • Make the required status checks satisfied another way (e.g. a lightweight no-op check) if full CI is skipped.
• Ensure any change does not break branch protection / merge requirements for the release PR.
• Ensure the post-merge push: main run (which deploys Pages and tags the release) is unaffected.

Acceptance criteria

• A decision is documented on whether/how to prevent duplicate CI runs for release-please PRs.
• If implemented, release PRs no longer trigger redundant full CI runs, while still being mergeable under branch protection.
• The post-merge main pipeline (lint + Pages deploy + release) continues to work.

Refs the release-please workflow (.github/workflows/release-please.yml).