feat(ship): decompose High-risk+Large units instead of one implementer

[BorisTyshkevich]

What & why

A single approved plan handed to one fresh coding agent works for most /ship units, but a genuinely large one reliably exhausts one agent's context before finishing — observed live on issue #585 phase 0 (a ~30-file plan across Docker orchestration, a precision corpus, a parity harness, and evidence generation): the first implementation attempt hit ~65% context after its first commit.

• per-issue-cycle.md gets an explicit Large flag alongside the existing risk classification: High-risk units additionally state whether they're Large (likely to exceed one coding agent's session), with a one-line justification. Most units are not Large, and Large is not inferred from risk alone — a High-risk unit can still be small (e.g. a narrow auth fix).
• SKILL.md step 2.3 branches on it: High + Large runs references/decompose-and-implement-loop.workflow.mjs instead of spawning one implementer. Fable/high proposes an ordered, dependency-respecting sub-task breakdown — grounded against whatever is already committed on the branch (not just the plan in the abstract), so a partial prior attempt's real progress doesn't get re-planned or redone. The script then runs one fresh Sonnet agent per sub-task, strictly sequentially on the same branch.

Sequential, not parallel-worktree, deliberately: the problem being solved is context exhaustion, not wall-clock speed, and a sub-task's declared file scope is a claim from the decomposition agent, not a mechanically verified guarantee — concurrent writes would add real conflict risk (two sub-tasks both wanting to touch package.json, say) for a benefit this doesn't need. Discussed and narrowed down from a more rigid alternative (a decomposition graph baked into the reviewed plan itself) — rejected because decomposition benefits from seeing what's actually been implemented, which doesn't exist yet at planning time, and because forcing a machine-parseable graph into a ChatGPT-authored prose plan document would add exactly the kind of parsing fragility #616 just finished fixing for the plan-author format itself.

skills/ship/tests/*.test.mjs (plain node --test) is green: 8/8.

Checklist

• Tests added/updated in the same change as the code (this skill's own node --test suite — N/A to product vitest gate)
• npm test (product coverage gate) — N/A, this only touches skills/ship/
• npm run build — N/A, same reason
• Layers (src/core/src/net/src/ui) — N/A, same reason
• No new runtime dependency
• README/CHANGELOG — N/A, tooling-only change, no deployed-product behavior change
• Reconciled tracked work — N/A, no roadmap/issue link