prioritize PR overview by project board and fix stale changelog placement

[maybeec]

Implemented changes:

Two agent instruction workflows were producing incomplete or wrong results. Both are fixed here, and both are mirrored into .github/prompts/ so GitHub Copilot and Claude Code stay on the same instructions.

report-pr-overview — prioritize by the project board

The report was built purely from the GitHub PR view, which ignores the workflow actually documented in project-board.adoc. It now reads the IDEasy board (project #5) and uses it to prioritize:

• PRs are grouped by pipeline column, distinguishing Team Review (peer review) from 👀 In review (final review by the PO), and PRs parked in non-review columns are surfaced as misplaced.
• The board's assignee convention (reviewer = assignees − author) determines review ownership, so a PR with no reviewer assigned is reported as a first-class finding instead of looking healthy.
• Priority and Size drive ordering (high priority + small size first), and a board-hygiene section reports missing metadata, wrong columns, PRs absent from the board, and reviewer load per person.
• New priority class A0 — "the board says this review is mine" — outranks the GitHub-derived classes. New class A4 catches a COMMENTED review thread left unresolved while the author pushed on; the previous spec only recognised CHANGES_REQUESTED and silently missed these.

sync-prs — fix changelog entries stranded under released sections

Placement was only ever checked while resolving a conflict. But a PR opened while 2026.07.001 was current keeps its bullet under == 2026.07.001; once that release ships the entry is stranded, and because the bullet sits in a different region of the file than main's additions this usually produces no merge conflict at all — so the sweep never looked at it. Real examples among currently open PRs: #1878 has its bullet under == 2026.05.001 (three releases back) while its milestone says 2026.08.001, and #2053 sits under the already-released == 2026.07.001.

• Changelog placement is now audited for every PR, conflict or not, by locating the PR's own bullet and walking back to its enclosing == heading — it does not assume the bullet is near the top of the file.
• A new step 0 resolves the target release section once, from .mvn/maven.config (-Drevision=<version>-SNAPSHOT, the authoritative next open release per the DoD), cross-checked against the changelog's first heading and the earliest-due open milestone. Disagreement stops the run rather than guessing.
• Released sections are treated as frozen: never written to, never moved into. Creating a new == <version> heading is explicitly out of scope — that is the release manager's commit.
• Milestone drift is reported with a ready-to-run gh pr edit command rather than written silently, since PR metadata is outside this workflow's remit.

Both — resolve the current release from the live remote

Both workflows resolved the current release by reading CHANGELOG.adoc from the local checkout. On a stale clone that yields a wrong answer: it reported "release 2026.07.002 shipped with no changelog section" when live main was perfectly fine. Compounding it, git fetch can fail silently while gh still works, so a clean git status proves nothing about freshness. Both now read CHANGELOG.adoc and .mvn/maven.config from the live remote via gh api, and only report a mismatch when the live files actually disagree.

Also recorded along the way: cheaper data-gathering (board pagination, one-call reviewer counts) and environment gotchas that cost real calls — quoting '@me' in PowerShell, preferring bash for --jq with embedded quotes, and stripping non-ASCII before printing board field names.

---

Testing instructions

These are agent instruction files only — no product code, no build impact. Verify by running the commands:

1. Run /report-pr-overview (Claude Code) or the report-pr-overview prompt (Copilot). Confirm the output groups PRs by board column, flags PRs with no reviewer assigned, and reports board hygiene gaps. Cross-check a few rows against the board.
2. Confirm the reported current milestone matches -Drevision= in .mvn/maven.config on main and the first == <version> heading in CHANGELOG.adoc on main — and that it stays correct even with a deliberately outdated local clone.
3. Run /sync-prs. Confirm it reports the resolved target section plus the sources it checked, and that it flags #1695: Clone settings to temporary directory, analyse, and then move #1878 and #1933 Added GUI console pane #2053 as changelog entries needing re-homing. Verify it never proposes writing into a released section or creating a new == heading.

---

Checklist for this PR

• When running mvn clean test locally all tests pass and build is successful — not applicable, documentation/instruction files only, no code or build files touched
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only. — no issue exists for this; title only
• PR top-level comment summarizes what has been done and contains link to addressed issue(s) — no addressed issue; the referenced PRs #1695: Clone settings to temporary directory, analyse, and then move #1878 and #1933 Added GUI console pane #2053 are linked as examples
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs) — there is no issue
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled with internal — no changelog entry: the changelog reflects only public changes relevant for end-users (DoD.adoc), and these are internal agent instructions
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

[coveralls]

Coverage Report for CI Build 30200137633

Coverage increased (+0.03%) to 72.594%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	16958
Covered Lines:	12832
Line Coverage:	75.67%
Relevant Branches:	7584
Covered Branches:	4984
Branch Coverage:	65.72%
Branches in Coverage %:	Yes
Coverage Strength:	3.2 hits per line

---

💛 - Coveralls