fix(skill): size extraction chunks by output, not just file count

[STiFLeR7]

Summary

Fixes #1758 — Part B2 semantic-extraction subagents can silently crash past the ~64k output-token per-turn limit on large/deep-mode chunks, and the missing chunk file is misdiagnosed.

Root cause

Step B1 sizes chunks purely by input file count (20-25), with no accounting for expected output volume — which varies a lot with --mode deep (more INFERRED edges per file) and document density. Each subagent must write its entire chunk's extraction in a single Write call within a single turn; a chunk whose output exceeds the model's per-turn output-token ceiling doesn't get truncated — the turn simply ends before Write happens, so the chunk file never appears on disk at all, and that chunk's extraction is silently lost. Step B3's existing diagnosis for a missing chunk file only considers one cause ("subagent was likely dispatched as read-only"), which is indistinguishable from an over-the-limit crash purely from the missing file.

Fix

Two of tools/skillgen/fragments/core/'s per-platform fragments dispatch subagents this way — core.md (claude and everything else that shares it) and devin.md:

• Reduce chunk size to 10-15 files when DEEP_MODE=true.
• Note the per-turn output ceiling explicitly in Step B1, with guidance for the subagent to keep extraction proportionate on unusually dense corpora even at the reduced chunk size.
• Give Step B3 a second diagnosis branch: a missing chunk file could be either read-only dispatch or an output-limit crash, and both need surfacing.
• Update the pre-dispatch timing/agent-count estimate to account for the smaller deep-mode chunk size.

Not touched: aider.md's Step B2 is sequential, single-context file-by-file processing (no parallel subagent dispatch, no single-turn-single-Write-call constraint), so this failure mode doesn't apply there and I didn't want to add misleading guidance to a mechanism that doesn't have the bug.

Not attempted: the issue's suggestion 3 (incremental writes across multiple Write/Edit calls so a chunk degrades to "wrote N of M nodes" instead of losing the whole chunk) — flagged in the issue itself as "more invasive." That would need actual subagent-prompt-protocol changes, not just a chunking/diagnosis tweak, and is a judgment call for a maintainer.

Verification

Regenerated all derived artifacts via python -m tools.skillgen --bless and confirmed python -m tools.skillgen --check passes clean ("134 artifact(s) match committed output and expected/"). Verified the diff scope via git diff --stat (not just git status, which flags many more files due to autocrlf line-ending bookkeeping with no real content change on this Windows checkout) — the real content diff touches exactly the two edited fragments plus the 15 platform-specific renders that depend on core.md (skill.md + 14 skill-<platform>.md files) and their expected/ snapshots. skill-aider.md and its snapshot are correctly untouched.

Disclosure

Prepared with AI assistance (Claude Code). I traced the actual chunking/dispatch/diagnosis logic in the fragment sources (not the rendered graphify/skill.md, which turned out to be a generated artifact — I initially hand-edited it directly, caught that the regeneration pipeline would overwrite it, and redid the edit against the real fragment sources instead) before making this change, and used the repo's own tools.skillgen --check/--bless drift guard to verify the derived artifacts are consistent rather than hand-editing them.