Extract the post-merge-systemize engine (fetch + digest + heartbeat) from cs-toolkit

[topij]

Sibling of #6. .claude/commands/post-merge-systemize.md (400 lines) specifies four engine scripts the kit does not ship. All four exist in cs-toolkit:

• scripts/fetch_github_prs.py — merged-PR fetcher → state/cache/
• scripts/digest_merged_prs.py — ~20× slimmer; the thing that keeps the run inside a scheduler timeout
• scripts/heartbeat_cli.py — step-boundary heartbeats
• scripts/nightly_digest.py — related digest path

Why this one matters beyond the skill. These are the only concrete implementation of Principle #9 (deterministic scaffolding around LLM steps — pre-fetch, slim, cap the input, heartbeat, resume). README claims #9 is "woven into the skills and scripts"; in the shipped kit it is only present in pr_watch.py's seen-set. Vendoring the digest + heartbeat pair would make #9 real rather than aspirational, independent of whether the systemize skill itself ships.

Work

1. Vendor heartbeat_cli.py first — it is the most generic and least coupled, and any long-running kit workflow can use it.
2. Vendor the fetch/digest pair behind the same forge abstraction as Extract the friction-triage engine from cs-toolkit behind a tracker adapter #6 (gh is already the kit's assumed CLI).
3. Config-drive lookback_days, pattern_threshold, batch_size, single_pass_max_prs, review_sources, operator_login.
4. Correct the skill banner; correct README's Principle fix(engines): four hardcoded-literal bugs in the pre-push guard, pr-watch, and state_paths #9 claim either way.

Sequencing. After #6 — same adapter work, and the triage path is the one in weekly use.