ci: milestone.yml looks for the closed v1.5 milestone, so new items get none #2548

From the 2026-11-01 conventions audit, re-verified on 73add05a3. process.rst, "Milestones and the Project Board": milestone.yml gives an item the open milestone as it opens, and a milestone is closed at the final tag "with due_on set to the tag date".

• util/milestone.py milestone_title derives the title from __version__ = '1.5.1' in pcapkit/__init__.py, so it looks for PyPCAPKit v1.5, which is closed; the only open one is PyPCAPKit v1.6. The run for feat(application): dissect every TLS record in a TCP segment, not only the first #2517 (gh run view 41281457767) logs no open milestone is titled 'PyPCAPKit v1.5', so no item was given one. refactor(link): dispatch LinuxSLL's non-EtherType ARPHRD values through its own registry map #2510, fix(protocols): a TLS trial parse on TCP 443 that falls to Raw still emits SchemaWarnings #2516, feat(application): dissect every TLS record in a TCP segment, not only the first #2517 and fix(protocols): hold a trial parse's warnings whenever beholder may replace it (#2516) #2519 carry none, while chore(docs): centralize 1.6.0 changelog updates in one place, not per-feature-PR #2449 and ICMP/ICMPv6 checksum verification (deferred from #2446) #2470 to OSPF checksum verification and computation (one's-complement, queued with #2470/#2471) #2475 carry v1.6.
• PyPCAPKit v1.5 has due_on null; v1.3 and v1.4 carry their tag dates, and the v1.5.0 tag is 2026-10-29. The board also keeps a Release 1.5 view beside Release 1.6, where the page says to rename it.

Decision needed: how should the milestone follow a release?

1. When the version's milestone is closed, use the lowest open PyPCAPKit v<x.y> above it (util/milestone.py, workflows.rst).
2. Bump __version__ to 1.6.0.dev0 after each release, as releasing.rst's dev-version ruling asks of a version in development; the scheduled Vendor Update then cannot release until the suffix is removed by hand.
   Recommendation: 1, because it fixes the naming without touching the release gate or the version.
   Fix: on 1, change the lookup in util/milestone.py, then dispatch milestone.yml to backfill the items without one. Either way, set v1.5's due_on to 2026-10-29 and rename the Release 1.5 view.