[github-actions] Auto-resolve predictable PR conflicts for wiki pointer and changelog drift

[coisa]

Summary

Open pull requests sometimes become conflicted only because main moved the .github/wiki submodule pointer or because CHANGELOG.md gained adjacent entries while the branch was waiting. Those conflicts are repetitive and mechanical enough that we should evaluate resolving them automatically.

Problem

GitHub Actions does not give us a clean dedicated "PR is conflicted" trigger, so maintainers currently notice these cases only after a pull request turns red or becomes unmergeable. We have already seen Dependabot and automation-oriented branches require manual rebases just to reconcile:

• workflow-managed .github/wiki pointer movement; and/or
• straightforward CHANGELOG.md entry drift in Unreleased.

That is friction without much real judgment when the only conflict is one of those known surfaces.

Proposed Direction

Add a workflow that inspects pull requests after updates and, when GitHub reports merge conflicts, checks whether the conflict scope is limited to predictable automation-managed files.

If the conflict is limited to:

• .github/wiki; and/or
• CHANGELOG.md

then the workflow MAY attempt an automatic resolution and push the refreshed branch.

Acceptance Criteria

• The repository has an automated path that can detect pull requests whose mergeability has degraded after main moves.
• The implementation uses supported GitHub event and API surfaces to inspect mergeability rather than assuming a dedicated conflict event exists.
• Automatic resolution is attempted only when the conflict scope is limited to .github/wiki and/or CHANGELOG.md.
• .github/wiki resolution treats workflow-managed submodule pointer movement as expected automation state.
• CHANGELOG.md resolution preserves both sides of non-overlapping Unreleased entries instead of dropping one side silently.
• When the conflict includes any other file, the workflow MUST stop and leave the PR for manual resolution.
• The workflow emits a clear summary or comment describing whether it resolved the branch automatically, skipped because the conflict was out of scope, or could not determine mergeability yet.
• Tests or fixture coverage exercise the changelog-only, wiki-only, and mixed-scope conflict cases where practical.

Notes

This should stay conservative. The goal is not "auto-resolve any PR conflict"; the goal is to automate two classes of conflicts that are already highly patterned in this repository.

Non-goals

• Resolving arbitrary source-code or workflow conflicts automatically.
• Replacing normal human review for pull requests with real semantic merge decisions.
• Making conflict resolution mandatory for every pull request workflow.