fix(pr-pipeline): the unrunnable-criterion hold loses its split recommendation behind needs_human #9375

Refs: #9291

Problem

#9367 (closes #9291) holds an issue whose done-when the lane cannot perform, but on its first live case the recommended split never reached the issue. Canary #9372 (filed 2026-10-23 08:02Z: a README count fix plus "Run /harness-config:audit on a Windows 11 host ...") got status: needs-decision and needs-human with only the reusable's fixed note: "Automated triage handed this issue to a maintainer." It carried no split and no item list, and its work class was "none".

Likely cause: the new rubric clause in .github/workflows/intake-triage.yml sends these items through the intent flag, and the intake model escalated with needs_human. A needs_human escalation posts only the reusable's fixed note and drops the lane comment (ci-workflows intake-triage.yml:189-194), so admit.mjs's refusal comment with the split never runs.

Done when

• An issue whose only blocker is an unrunnable done-when item reaches status: needs-decision with a comment that names the item(s) and recommends the split. Either the intake verdict keeps needs_human false and lets admit.mjs refuse, or the split text survives the escalation.
• The lane-checkable part is not handed to a person: the comment recommends it as an admissible issue.
• A test covers a Windows-host done-when item producing the split comment.

Evidence

• Canary docs(harness-config): README says six configuration-health skills; there are nine #9372: labels status: needs-decision, needs-human, a single intake comment with "Proposed work class: none".
• PR fix(pr-pipeline): hold an issue whose done-when the lane cannot perform #9367 (merged 08:01:17Z).