Add milestone automation for merged PRs

[kraftbj]

Fixes #152

Summary

Adds a GitHub workflow that automatically manages milestones for merged PRs. Inspired by Gutenberg's project-management-automation, but simplified for our release process.

Behavior

Current State	Action
No milestone	Assigns to earliest open milestone
Open milestone	Keeps it as-is
Closed milestone	Updates to earliest open milestone + adds comment

Milestone Selection Priority

1. Open milestones with a due date (earliest first)
2. Open milestones without a due date (sorted by version number, e.g., 6.8.1 before 6.9.0)

Key Differences from Gutenberg

Aspect	Gutenberg	SCF
Trigger	push to trunk	pull_request_target closed
Milestone creation	Auto-creates next milestone	Uses existing milestones
Closed milestone handling	N/A	Updates + comments
Version calculation	From package.json	Sorts existing milestones

Comment on Closed Milestone

When a PR is merged with a closed milestone, it's automatically moved and a comment is added:

This PR was merged with a closed milestone (X.Y.Z). It has been automatically moved to A.B.C.

If this was intentional (e.g., a backport), please manually update the milestone.

Test plan

• Merge a PR without a milestone → should be assigned to earliest open milestone
• Merge a PR with an open milestone → should keep the milestone
• Merge a PR with a closed milestone → should update and add comment

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props kraftbj, bernhard-reiter, priethor.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.01%. Comparing base (7756c10) to head (cccc504).

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk     #356      +/-   ##
============================================
- Coverage     53.67%   51.01%   -2.66%     
  Complexity     4410     4410              
============================================
  Files           298      298              
  Lines         39424    39424              
============================================
- Hits          21161    20113    -1048     
- Misses        18263    19311    +1048     

Flag	Coverage Δ
e2e-js	44.95% <ø> (-0.13%)	⬇️
e2e-php	38.44% <ø> (-4.00%)	⬇️
javascript	15.07% <ø> (ø)
phpunit	29.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ockham]

I'm not entirely sure about the closed milestone behavior. I'm not sure I like the idea that an aspect of a PR that I set manually -- the milestone -- might be automatically changed when I merge it. I guess it's meant to help me in case I forget to assign a new milestone if the previous one was already closed, but to me, it seems like it actually removes confidence, because now it feels like I'll always have to double-check.

Maybe I'm biased by my experience with Gutenberg, where the milestone is closed when the RC is published, meaning that any bugfixes that need to go in afterwards and before the stable version is released will need to be assigned a closed milestone. I guess the release workflow is different for SCF (?)

Anyway, how about we don't update the milestone if it's closed and instead add a comment to notify the PR author to make sure they're aware?

[kraftbj]

I'm fine backing off the closed milestone process. It may be a solution in search of a problem.