Milestone-scoped census: the loop works one milestone (sprint) at a time

[robercano-ghbot]

What

Milestones represent versions (SCRUM sprints). The census should drain the CURRENT milestone and then idle — never wander into future versions. The idle gap after a milestone completes IS the PO feedback phase.

Spec

• Current milestone = the open milestone (REST: /milestones?state=open) with the lowest version-ish title that has at least one open planned issue.
• Census considers ONLY that milestone's issues for advance (feedback/merge phases unaffected — open PRs are always serviced).
• Fallback: no open milestone with planned issues → today's behavior (unmilestoned planned issues), so the feature is opt-in and degrades gracefully.
• Emit milestone=<title> + milestone_open= lines in census output for the cockpit/roadmap; log a milestone-complete event when the last issue in the current milestone closes.
• Composes with the priority sort (see the priority-labels issue): sort within the milestone scope.
• gh 2.4.0 constraint: ALL milestone reads via REST gh api (no gh milestone commands, no GraphQL).

Acceptance

• With two open milestones both holding planned issues, only the lower-versioned one's issues advance.
• Draining the current milestone idles the loop even though the next milestone has planned issues WITHOUT the planned label... (correction: next milestone's planned issues DO qualify once the current milestone has none open — 'current' recomputes each tick; the owner controls phase boundaries by WHEN they label the next milestone's issues planned).
• loop-census.test.sh scenarios for scoping, fallback, recompute-on-drain.

🤖 Generated with Claude Code