Fix close-milestone workflow ordering: close milestone before moving unfinished issues
## Summary
Correct the ordering of the sprint close-out workflow so the milestone is **closed before** unfinished issues are moved to the next sprint. This preserves GitLab's built-in burndown / completed-vs-incomplete snapshot, which GitLab captures at the instant of closure and only counts issues still attached at that moment.
## Work Track
AI Marketing
## Context / Background
During the Sprint 6 → Sprint 7 close-out we hit this first-hand: moving open issues to the next sprint *before* closing the milestone caused them to vanish from GitLab's native end-of-sprint report (counted as neither completed nor outstanding), understating the sprint's in-flight work. Our own history-based `sprint-stats` report is unaffected by the order, but GitLab's built-in reports are not. This ticket captures the fix to the tooling so the mistake can't recur.
## Tasks
- [x] Reorder `scripts/run-close-milestone.sh` so the close step runs before the move step (report → close → move → credit).
- [x] Update `skills/close-milestone/SKILL.md` to match: close (§4) before move (§5), with rationale and the drupalcode HTTP 301 milestone-write-block note.
- [x] Fix the `MOVE_OPEN_TO_IID` env-var docs ("after closing" instead of "before closing").
- [x] Fix step cross-references in the skill's "Related skills" section (sprint-stats = step 3, contribution-credit = step 6).
## Acceptance Criteria
- [x] Close-milestone script and skill both document and execute close-before-move.
- [x] `bash -n scripts/run-close-milestone.sh` passes.
- [x] The 301 milestone-write-block caveat is documented in the skill.
## AI Usage
- [x] AI Assisted Issue — This issue was generated with AI assistance, but was reviewed and refined by the creator.
issue