fix(skill): per-type incremental kinds for the --update runbook (#2033)

[HerenderKumar]

Fixes #2033.

Problem

Both calls in the --update runbook fall back to defaults that are wrong for this pipeline (verified on current v8, edec9ea):

1. detect_incremental() defaults to kind="semantic", which treats a missing semantic_hash as "changed". Code files never receive semantic extraction (the skill sends only docs/papers/images to subagents), so on an AST-built corpus — e.g. one maintained by graphify update, --watch, or the git hook, which stamp kind="ast" — every code file reports as changed. That's the 629-reported vs 12-real blowup in the issue.
2. save_manifest() defaults to kind="both", forging a semantic_hash for every corpus file — including docs that were never semantically extracted — so a later semantic pass considers them done and silently never runs.

Why not a blanket kind='ast'

The issue suggests passing kind='ast' at detection. That fixes the code-file blowup but breaks the other direction: a doc downgraded by an AST-only rebuild (kind="ast" stamps clear its semantic_hash on content change — that's the documented catch-up signal, and the silent-downgrade scenario of #2014) would compare by its freshly-stamped ast_hash and report unchanged, so the runbook would never semantically re-extract it. Code and docs need different hash columns.

Fix

• detect.py: detect_incremental() gains kind="auto" — code files compare against ast_hash, everything else against semantic_hash. One-line dispatch inside the existing per-type loop; "semantic"/"ast" behavior untouched.
• Shared references/update.md fragment: detection passes kind='auto'; the merge step replaces the single default-both stamp with two: kind='ast' over the corpus (preserves each untouched file's semantic_hash, clears it for changed files), then kind='semantic' over just the changed docs/papers/images/videos the semantic pass actually covered. On the runbook's code-only branch that set is empty, leaving exactly the kind='ast'-only stamp the issue asks for — one shared code path, no branch duplication.
• aider/devin monoliths: same kind='auto' detection fix (their legacy update flow never re-saves the manifest, so there's no stamping call to fix).
• tools/skillgen/gen.py: the monolith round-trip sanctions the new lines via _is_incremental_kind_fix_line, following the existing predicate convention; all artifacts and expected/ regenerated (--check, --audit-coverage, --schema-singleton, --monolith-roundtrip, --always-on-roundtrip all pass).

Verification

• 4 new regression tests in tests/test_detect.py (code-with-ast_hash-only unchanged; doc missing semantic_hash re-queued; changed code re-queued; doc with valid semantic_hash unchanged). The full 9-suite batch touching detect_incremental/skillgen matches the clean-v8 baseline failure-for-failure (remaining failures are pre-existing environment gaps: missing rapidfuzz/tree-sitter).
• End-to-end against the rendered graphify/skills/claude/references/update.md: every embedded python -c snippet parses; on a 5-file AST-built corpus (3 code + 2 docs) the old detection reports all 5 files changed, the new one reports 0 code files and only the 2-doc semantic backlog; after the two-stamp save, changed code carries a fresh ast_hash with no forged semantic_hash, covered docs carry a real semantic_hash, and a follow-up detection reports zero changes.

Residual (intentionally out of scope)

• A doc that is dispatched this run but whose chunk the LLM drops still gets stamped by the second call (it's in the changed set). That's strictly narrower than the current behavior (which stamps the entire corpus) and matching the CLI's dispatched-but-omitted tracking (save_manifest seeds stale semantic_hash from prior manifest, masking LLM-omitted docs — the re-run promised by #1890 never happens #1948) would need per-chunk bookkeeping the runbook doesn't have.
• graphify extract's own incremental path keeps kind="semantic" per the issue's scoping ("the full-pipeline path should keep kind="semantic"/"both"").