feat: merge changelogs pr when release gets published

[r0b1n]

Automatically merge the changelog PR when release gets published to Marketplace. Includes simple check that PR contains only allowed files" "package.xml", "CHANGELOG.md", "package.json".

[github-actions]

AI Code Review

⚠️ Approved with suggestions — low-severity items only, safe to merge

---

What was reviewed

File	Change
.github/workflows/PublishMarketplace.yml	Added "Merge changelogs PR" step after marketplace publish
automation/utils/bin/rui-merge-changelogs-pr.ts	New script: finds PR by release tag, validates changed files, squash-merges
automation/utils/src/github.ts	Added GitHubPR, GitHubPRFile interfaces; getPRByReleaseTag, listPRChangedFiles, mergePR methods
automation/utils/package.json	Added rui-merge-changelogs-pr bin entry and merge-changelogs-pr script
package.json	Added root-level merge-changelogs-pr script forwarding to automation-utils

Skipped (out of scope): pnpm-lock.yaml, dist/

---

Findings

⚠️ Low — Workflow step not guarded against fork PRs

File: .github/workflows/PublishMarketplace.yml line 62–65
Note: The workflow is triggered by release: published, which normally only fires from the base repo and not forks. However, workflow_dispatch can be triggered by anyone with write access. The new step uses secrets.GITHUB_TOKEN with merge permissions — no additional risk here, but worth documenting that the fork-guard is implicit (only users with write access can publish a release or dispatch the workflow).
This is informational only; no action required unless the team wants an explicit if: github.repository == 'mendix/web-widgets' guard.

---

⚠️ Low — getPRByReleaseTag silently returns the first PR when multiple exist

File: automation/utils/src/github.ts line 399 (new method)
Note: prs[0] is returned without checking whether more than one PR is associated with the commit. In practice this is rare, but if a commit is reachable from two open PRs (e.g. a hotfix cherry-pick), the wrong PR could be merged. Consider logging a warning or throwing SkipError when prs.length > 1.

if (prs.length > 1) {
    throw new SkipError(
        `Multiple PRs found for commit ${sha}: ${prs.map(p => `#${p.number}`).join(", ")}. Cannot auto-merge. Skipping.`
    );
}
return prs[0];

---

⚠️ Low — listPRChangedFiles does not paginate

File: automation/utils/src/github.ts line 410 (new method)
Note: The GitHub API returns at most 30 files per page by default (max 100 with ?per_page=100, and caps at 300 total). Changelog PRs are tiny so this is safe in practice, but the existing file-count validation (disallowed.length > 0) would silently pass for a PR with >100 files because the tail is never fetched. A comment documenting the assumed constraint would prevent future surprises.

---

⚠️ Low — mergePR does not pass a commit title/message

File: automation/utils/src/github.ts line 426 (new method)
Note: The PUT /pulls/{pull_number}/merge endpoint uses the PR title as the squash commit title by default. This is usually fine, but if the repo has a branch protection rule that enforces conventional commit format on merge commits, an auto-generated title could fail. Explicitly passing commit_title and commit_message would make the behavior predictable and auditable in the git log.

---

Positives

• SkipError pattern is clean — distinguishes expected no-op situations (no PR found, already merged) from real failures without polluting exit codes.
• Annotated-tag resolution (two-level dereference) is correctly handled and documented inline.
• File allowlist uses Set + at(-1) for clean basename extraction; the validation logic is easy to read.
• Existing ensureAuth() is reused consistently across all three new methods — no auth duplication.
• Action references in the workflow were already SHA-pinned with version comments before this PR; the new step inherits that pattern correctly (no new action refs introduced).