ci: set milestones automatically on close #2218

Milestones stopped being set after #1068 (2026-10-06): more than 1,100 closed issues and PRs had none. They are being backfilled by hand onto PyPCAPKit v1.5, using the rule the milestone already followed:

• Gets the milestone: a merged PR, or an issue closed as completed.
• Never gets it: a PR closed unmerged, or an issue closed as not planned (the gaps at Fix TCP reassembly coordinates (#349); add an end-to-end test tier #372, perf: cache struct.calcsize in FieldBase length property to eliminate per-field parsing overhead #551, perf: Optimize Protocol extraction by caching dynamically imported modules in ProtocolBase #563, corekit: reject short dynamic field buffers #571, ci(release): give a pre-release or .postN its base version's changelog #658, fix(corekit): give the MultiDict _missing sentinel @final and __bool__ #667, examples/legacy_smoke: four committed-capture counts become false when #697 lands, and README:23-24 already contradicts :118 #707 and others are all of this kind).

Proposal: a milestone.yml workflow, one task per workflow (#1967), with its logic in a util/ script and tests, as project-status.yml does with util/project_status.py.

• Triggers: issues: closed and pull_request_target: closed.
  • On a merged PR or a completed issue, it sets the open milestone named after the base branch's pcapkit.__version__: PyPCAPKit v<major>.<minor>.
  • On an unmerged PR or a not-planned issue, it removes any milestone.
• Missing milestone: if the milestone for the version does not exist, a warning annotation is emitted and nothing is created; creating the next milestone stays a manual release step.
• Backfill: workflow_dispatch re-runs the rule over every closed item that has no milestone.
• Security: pull_request_target runs only base-branch code, and no PR content is executed. Permissions are issues: write and pull-requests: write on that job alone.