feat: adapt apply scan window

[steipete]

Supersedes #401 after GitHub rejected maintainer pushes to its forked head because the current OAuth token lacks workflow scope. The published tree exactly matches the reviewed rewrite.

This keeps the original proposal's useful policy: untargeted close-apply scans start at 300 records and can grow to 600, then a capped 900, only after a full skip-heavy window closes nothing. Close limits, checkpoints, worker counts, live checks, and policy gates do not change. Comment-sync status now preserves the last close-health sample so the next close run has the right input.

The rewrite also extracts reusable shell helpers from the oversized apply step. Current main exceeds GitHub's 21,000-character workflow-expression limit and produces zero-job failures; this head is below a tested 20,000-character ceiling.

Proof:

• focused: 134/134
• full: 600 unit + 599 repair
• changed coverage: 100% lines, 89.17% branches, 100% functions
• full coverage: 76.64% lines, 70.60% branches, 83.91% functions
• bash -n, ShellCheck, actionlint, build, lint, format: clean
• AutoReview: no accepted/actionable findings, confidence 0.84
• published tree: 17d15b0bdf023eb8c1d41a700ea00faff7c06dbc (exact reviewed tree)

Co-authored-by: brokemac79 martin_cleary@yahoo.co.uk

[steipete]

Landed as a52b852.

Final proof: exact head fb2d036; 134 focused tests; 600 unit + 599 repair tests; changed/full coverage gates; build, lint, format, ShellCheck, and actionlint clean; AutoReview clean at 0.84 confidence; all required GitHub checks green (pnpm check 8m44s). GitHub accepted the repaired workflow and the prior zero-job sweep.yml parser failure did not recur.

Thanks @brokemac79 for the adaptive scan baseline.