ci: add CalVer release workflow

[davebarnwell]

Summary

This change adds a dedicated GitHub Actions release workflow that runs when a pull request is merged into main or master. After merge, the workflow checks out the merge commit, computes a deterministic vYY.MM.DD.n CalVer tag for that commit, pushes the tag, and creates a GitHub release with generated notes.

Without this automation, merges complete without any release artifact, which means consumers do not get a consistent version tag or release record for shipped changes. The immediate user-facing effect is that merged work is harder to consume and audit because there is no standardized post-merge versioning step.

The root cause is that the repository only had validation CI and no post-merge release pipeline. There was no workflow listening for merged pull requests, no logic for generating CalVer tags, and no release creation step tied to the merge commit.

The fix introduces a separate release.yml workflow so validation and release responsibilities stay isolated. The workflow only runs for merged pull requests targeting main or master, reuses the highest existing vYY.MM.DD.n tag already attached to the merge commit on reruns, otherwise derives the date portion from the PR merge timestamp and creates the next suffix for that day, verifies that any pre-existing remote tag points at the expected merge commit, and then creates the corresponding GitHub release. The README and changelog were updated to document the new behavior.

Validation

• Parsed .github/workflows/release.yml successfully with PyYAML
• Ran vendor/bin/phpunit -c phpunit.xml.dist

[Copilot]

Pull request overview

Adds a post-merge release automation pipeline so merges to main/master produce a consistent CalVer tag and a corresponding GitHub Release, and documents the behavior.

Changes:

• Introduce a new Release GitHub Actions workflow that runs on merged PRs and creates/pushes CalVer tags and GitHub Releases.
• Document the new release automation in README.md.
• Add an entry to CHANGELOG.md noting the automated tagging/release behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
.github/workflows/release.yml	Implements post-merge tagging and GitHub Release creation logic.
README.md	Documents automatic CalVer tags/releases for merged PRs.
CHANGELOG.md	Notes the addition of automated CalVer tagging and releases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

remote_sha is derived via git rev-list -n 1 "$TAG", which resolves the local tag ref. If a tag is created/updated on origin after the earlier git fetch --tags, this can fail (tag not present locally) or compare against stale data. Prefer extracting the commit SHA directly from git ls-remote --tags origin "refs/tags/$TAG" (handling annotated tags by selecting the ^{} line when present) so the verification is based on the remote state you just checked.

[Copilot]

Using pull_request_target with contents: write runs in the privileged base-repo context. Even though this workflow checks out the merge commit, it’s generally safer to trigger releases from a push event on main/master (or a workflow_run from CI on main), so untrusted PR events can’t ever invoke a write-capable workflow. Consider switching the trigger to on: push and deriving the CalVer date from the merge commit metadata (or querying the merged PR via the API if you need the PR merge timestamp).