refactor(generate): make the step graph directly testable and harden it

[dyoshikawa]

Summary

• Follow-up to refactor(generate): enforce shared-file write order via a declarative step graph #2081 / PR refactor(generate): enforce shared-file write order via a declarative step graph #2081, which refactored generate()'s shared-file write ordering into a declarative step graph (dependsOn + writesSharedFile), topologically sorted and validated by resolveExecutionOrder/assertSharedFilesOrdered.
• Extracts the graph's static shape (id, writesSharedFile, dependsOn) into an exported GENERATION_STEP_GRAPH, separate from the run closures that need a live config/logger. This lets tests exercise resolveExecutionOrder against the real graph instead of a hand-copied stand-in.
• Restores short rationale comments on each non-obvious dependsOn edge, explaining which shared file forces the ordering (the original PR's prose comments were dropped when the graph became declarative).
• Adds a test that walks every dependsOn edge and asserts it corresponds to either an actual overlapping writesSharedFile token or the one documented value-dependency (rules reading the skills step's output) — this catches a stale or unjustified edge, and combined with the existing assertSharedFilesOrdered runtime check (which catches a missing edge for a real overlap), the two together keep the declared edges honest in both directions.
• Adds a test pinning the full execution order of the real graph, so the mcp step's position (2nd → 5th after the refactor) — or any future reordering that changes runtime behavior — is caught rather than silently regressing.

Not addressed (left for a follow-up if needed)

• Fully automated verification that writesSharedFile enumerates every shared file across all tool targets (proving there's no un-declared overlap) would require cross-referencing each feature's getSettablePaths() per tool target, which is a materially larger undertaking than this hardening pass. The new edge-justification test narrows the risk (no stale/incorrect edges) but doesn't fully close this gap.
• The two "effectively unreachable" defensive checks flagged in the original issue (if (!skillsResult) throw, get()'s missing-result throw) were left as-is — they're a cheap safety net against future graph regressions and only rated low/nit.

Test plan

• pnpm cicheck passes
• New tests: graph well-formedness, edge-justification, and full execution-order pinning, all run against the real GENERATION_STEP_GRAPH
• Existing generate.test.ts and resolveExecutionOrder tests still pass unmodified

Closes #2082

[dyoshikawa]

@dyoshikawa Thank you!