feat: add milestone management workflow

[hussain-s]

Add milestone management automation for release tracking.

Changes

• add .github/workflows/milestone-management.yml to auto-assign milestones on merged PRs
• support merged PRs targeting main and release/test branch patterns
• add workflow_dispatch support to create or re-open upcoming X.Y.Z milestones
• document milestone naming and branch mapping in scripts/README.md
• add scripts/milestone_management_preview.py for local milestone-selection checks
• add unit coverage for the branch-to-milestone logic in tests/test_milestone_management_preview.py

How I tested this

• ran .venv311/bin/python -m pytest tests/
• ran PRE_COMMIT_HOME=.pre-commit-cache .venv311/bin/pre-commit run --all-files
• ran .venv311/bin/python -m pytest tests/test_milestone_management_preview.py
• exercised scripts/milestone_management_preview.py manually for main, release branches, and unmanaged branches

Notes

• milestone titles follow the X.Y.Z convention requested in issue ci: milestone management workflow #722
• merged PRs to main pick the earliest open X.Y.Z milestone
• merged PRs to release/test branches use the milestone inferred from the branch name
• milestone creation is manual through workflow_dispatch; merged-PR assignment is automatic once milestones exist

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[andreahlert]

burr supports py3.9 per pyproject.toml but str | None on line 42 needs 3.10+. import breaks on 3.9 and the test file blows up with it since it loads the module at top level.

Suggested change

	import argparse
	import re
	from __future__ import annotations
	import argparse
	import re
	import sys

[hussain-s]

address in next revision

[andreahlert]

this fails the workflow run on every merge until a milestone exists. a console.warn + return would skip quietly instead of spamming failed-run notifications.

Suggested change

	if (!milestone) {
	throw new Error(
	"No open X.Y.Z milestone found for main. Create one with the workflow_dispatch path first."
	console.warn(`#${pr.number}: no open X.Y.Z milestone for main, skipping assignment.`);
	return;

[hussain-s]

address in next revision

[andreahlert]

the JS in the workflow has the same logic but no tests. preview script mirrors it today, will drift later. worth testing the JS too, or at least a comment in both files saying they must stay in sync.

[hussain-s]

address in next revision

[andreahlert]

missing coverage for release/0.43.1 (slash variant), apache-burr-0.43.1-release, and the release-0.43 minor fallback. regex handles them but nothing exercises that path.

[hussain-s]

address in next revision

[github-actions]

This PR has been inactive for 16 days after receiving review feedback.
Converting to draft.

Please mark it as ready for review when you have addressed the comments.
If no activity occurs within 90 days, it will be closed automatically.

[elijahbenizzy]

+1, nice work — matches #722 spec well, tests exercise the Python side thoroughly, CI green.

One follow-up worth tracking: the branch-to-milestone regex table lives in both .github/workflows/milestone-management.yml (JS) and scripts/milestone_management_preview.py (Python), with only comment-level "keep in sync" markers. Since only the Python side has tests, the JS can drift silently. Not a blocker for landing this, but worth an issue for a follow-up — either have the workflow shell out to the Python script so it's a single source of truth, or add a CI job that runs the JS logic against the same test cases as the Python tests.

Approving; happy to see this land as-is with the duplication tracked separately.