ci: auto-create GitHub Release on tag push (port mcp-synology github-release job)

[cmeans-claude-dev]

Closes #126. Adds a github-release job to publish.yml that runs after publish-pypi on every tag push. The job awk-extracts the matching CHANGELOG section and creates (or updates) a GitHub Release with those notes. Closes the Releases-page-drift gap that surfaced after v2.4.0 / v2.5.0 / v2.5.1 all landed on PyPI without matching GitHub Releases (manually backfilled on 2026-05-06).

What landed

.github/workflows/publish.yml:

• New github-release job, needs: publish-pypi. Release only lands after the wheel is on PyPI.
• permissions: contents: write enables gh release create / gh release edit.
• Step 1 — awk-extract: anchored to ^## \[VERSION\] (literal brackets, matching the Keep-a-Changelog format mcp-clipboard uses), then strips leading blank lines, then sets a use_changelog=true/false step output.
• Step 2 — idempotent create-or-update: if a Release for the tag already exists, edit it in place rather than failing with HTTP 422. Fall through to --generate-notes (auto commit-list) when the CHANGELOG has no matching entry.

CHANGELOG.md: [Unreleased] / ### Added entry.

Pattern source

Ported from cmeans/mcp-synology publish.yml. One CHANGELOG-format adaptation: mcp-synology uses ## 0.5.2 (2026-05-01) headings (no brackets) and its awk matcher anchors on ^## VERSION( |\(). mcp-clipboard uses Keep-a-Changelog ## [2.5.1] - 2026-05-05 (literal brackets), so the awk matcher here anchors on ^## \[VERSION\] instead. Verified locally against the live CHANGELOG: extraction returns the right notes block for v2.5.1, v2.5.0, v2.4.0, and v2.3.0.

Verification

• uv run pytest -q: 599 passed, 19 deselected, 5 xfailed (no runtime code touched).
• uv run ruff check src/ tests/ scripts/: clean.
• python scripts/sync-server-json.py --check: in sync (2.5.1).
• Local awk validation against the four most recent versions in the live CHANGELOG: each returns the correct notes block, with the next ## [ heading correctly terminating the section.

Out of scope

• Backfilling Releases for v2.4.0 / v2.5.0 / v2.5.1 — already done manually on 2026-05-06.
• SHA-pinning the existing actions/checkout@v6 and actions/setup-python@v6 references in publish.yml (mcp-synology uses SHA pins); that's a separate hardening pass.
• Hand-crafted release titles like the v2.3.0 one. The awk extraction uses the bare vX.Y.Z tag as the title; richer titles can be a follow-up.

Test plan

• CI green across lint, typecheck, test (3.11/3.12/3.13), integration-x11, version-sync, validate-server-json. (publish.yml only fires on tag push, so this PR's CI doesn't exercise the new job — it'll exercise on the next release tag.)
• Next release tag pushed produces a GitHub Release with the matching CHANGELOG notes (no manual gh release create needed).
• Re-running a partially-failed publish.yml doesn't crash on "release already exists"; it edits in place.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cmeans]

QA Round 1 — Ready for QA Signoff

Single round, zero findings. The diff is faithfully ported from cmeans/mcp-synology publish.yml with the documented Keep-a-Changelog adaptation (awk anchor ^## \[VERSION\] instead of mcp-synology's ^## VERSION( |\()).

Code review. The job is small, well-commented, idempotent, and gated behind publish-pypi so the GitHub Release only lands after the wheel is on PyPI. permissions: contents: write is correctly scoped to this job only. The gh release view precheck before create vs edit handles re-runs of partially-failed publishes (avoids HTTP 422 on duplicate-tag create). The --generate-notes fallback is correctly only wired into the create branch — gh release edit cannot regenerate auto notes, so the existing body is preserved on re-run when no CHANGELOG entry exists. sed -i '/./,$!d' is the standard idiom to drop leading blank lines, so the Release body never starts with an empty paragraph.

Pattern-port fidelity. Side-by-side diff against mcp-synology publish.yml:117-180 shows: same needs:, same permissions, same fetch-depth: 0, same idempotency logic, same --generate-notes fallback. Only intentional change is the awk anchor format.

Awk extraction — live-verified against the current CHANGELOG.md:

Version	Extracted lines	Result
v2.5.1	17	starts with ### Fixed (mcp-name token)
v2.5.0	59	starts with ### Added (PRIMARY/Wayland + markdown + registry)
v2.4.0	52	starts with ### Fixed (macOS osascript stdin)
v2.3.0	164	starts with ### Added (reset_backend_cache helper)
v9.9.9 (negative test)	0	empty → use_changelog=false → falls through to --generate-notes

Each section terminates correctly at the next ## [ heading.

Local verification on head 41010f6:

• uv run pytest -q → 599 passed, 19 deselected, 5 xfailed in 4.10s. The 19 deselected are the integration-marked tests (pyproject.toml: addopts = "-m 'not integration'"); they run separately in the integration-x11 CI job, which is green on this PR.
• uv run ruff check src tests scripts → clean.
• uv run mypy src → clean (4 source files).
• python scripts/sync-server-json.py --check → in sync at 2.5.1.
• Pre-existing 13-check CI suite all green incl codecov/patch.

Test-plan status. Checkbox 1 (CI green) is satisfied — ticked in the PR body. Checkboxes 2 (next tag push produces a Release with CHANGELOG notes) and 3 (re-run on partial failure edits in place rather than 422'ing) are post-merge verification — they only exercise on the next real vX.Y.Z tag push. Out-of-scope items in the PR body (SHA-pinning the existing @v6 action refs, hand-crafted release titles like v2.3.0:) are noted and not blocking.

Verdict: Ready for QA Signoff. Awaiting maintainer QA Approved.

[cmeans]

Adding Ready for QA Signoff — local verification clean (599 passed / 19 deselected integration / 5 xfailed; ruff, mypy, sync-server-json all clean), CI fully green, awk extraction live-verified against the current CHANGELOG for v2.5.1/v2.5.0/v2.4.0/v2.3.0, zero findings on round 1. Awaiting maintainer QA Approved.

[cmeans]

LGTM