ci(framework): close a milestone when its last issue closes

[blafourcade]

🎯 What & why

A milestone stays open after its last issue closes. Its Friday due date then reads as overdue (see #6 "Onboard new users": 6/6 closed, due 2026-07-10, still open on 2026-07-13), and a roadmap view keeps rendering the finished group. GitHub Projects has no rule to close a milestone or hide a finished group — the built-in workflows only set item fields.

🛠️ How it works

close-finished-milestones.yml closes any open milestone with closed_issues > 0 && open_issues == 0.

• The closed_issues > 0 guard leaves an empty milestone alone — a freshly created bucket is not finished work.
• Triggers: issues: [closed] (the moment a milestone can become finished) and a Monday cron as a safety net.
• Token: the built-in GITHUB_TOKEN with issues: write. No App token — closing a milestone is the issues API, no cross-branch push.
• Reopening a milestone by hand to add work is safe: the next run sees open_issues > 0 and skips it.

Dry-run against the live repo:

#6  closed=6 open=0  -> close   (Onboard new users)
#9  closed=0 open=3  -> skip    (Skills cost only what they use)

⚠️ Where it runs

schedule, issues, and workflow_dispatch triggers run only from the default branch (main). Merged here into next, the workflow does nothing until it reaches main via the weekly promotion. First real run is the Monday cron after that promotion, or the next issue close on main.

🧪 How to verify

yq e '.' .github/workflows/close-finished-milestones.yml >/dev/null && echo parses

# same selection the workflow makes
gh api --paginate 'repos/ai-driven-dev/framework/milestones?state=open' \
  --jq '.[] | select(.closed_issues > 0 and .open_issues == 0) | "\(.number)\t\(.title)"'

Once on main: workflow_dispatch it, then confirm #6 flips to closed.

✅ I certify

• I DO CERTIFY I READ EACH LINE OF THE PULL REQUEST BECAUSE I AM A SOFTWARE ENGINEER, NOT A AI PUPPY.