feat(rigging): setup-node dependency cache derived from the package manager

[submtd]

What

Closes #45. The generated node job's actions/setup-node step now carries the cache input, derived from the configured package manager, so CI runs restore the dependency store keyed on the lockfile instead of installing cold every run:

• npm → cache: "npm"
• pnpm → cache: "pnpm" (the existing pnpm-before-setup-node ordering is what makes this resolve; the comment in plan.py predicted this feature)
• yarn1 → cache: "yarn"
• bun → no cache input: setup-node's v7 source supports only npm/pnpm/yarn.
• yarn-berry → no cache input: setup-node resolves the yarn cache directory by running yarn --version during its own step, but rigging's corepack enable runs after setup-node — so a berry repo would be misdetected as the runner's Yarn 1.22 and a classic cache directory saved that berry never reads. Omitting the input beats emitting a silently useless one.

No stacks.node.cache knob — the input is safe and strictly faster for every manager that gets it, and a knob can be added later if a reason to opt out ever appears.

Verification

• The bun/berry claims were checked against the pinned SHA's actual source (docs/advanced-usage.md and src/cache-utils.ts at 8207627), not current docs.
• New tests: registry-exhaustive cache_key pin (a sixth manager forces a decision), parametrized positive and omission cases in the plan, with_ insertion-order pin, and an explicit test that python's setup step gained nothing.
• All nine node goldens gained exactly one line; node-bun.yml and node-yarn-berry.yml byte-identity-pin the omission. Full suite: 344 passed; all six plugin suites green (1453 total).
• Self-review by a fresh subagent returned "ready to merge" with only polish items, addressed in the follow-up commits (init-skill docs on why bun/berry see no cache line).

🤖 Generated with Claude Code

[submtd]

Self-review (author; reviewPolicy is review, so a comment satisfies the gate).

Correctness. The cache values are exactly the strings setup-node v7 accepts, verified against the pinned SHA's own cache-utils.ts rather than current docs. The pnpm ordering requirement (manager installed before setup-node so pnpm store path resolves) was already satisfied and is now load-bearing; the plan.py comment was updated accordingly. The two omissions are correct, not gaps: setup-node cannot cache for bun, and berry would be misdetected as the runner's Yarn 1.22 because corepack enable runs after setup-node.

Tests. Registry-exhaustive cache_key pin (adding a sixth manager forces a decision), parametrized emit/omit plan tests, with_ insertion-order pin, an explicit python-unchanged test, and golden byte-identity for all nine node goldens — with node-bun.yml/node-yarn-berry.yml pinning the omission itself. Each test was watched failing before implementation. 344 passed; all six plugin suites green.

Scope. Diff contains exactly the feature, its tests/goldens, the changelog entry, and an init-skill paragraph documenting the bun/berry omission (added after a fresh-context subagent review flagged the doc gap).

Changelog. Unreleased entry is user-facing and committed.

One honest caveat, per this repo's own standing rule: byte-identical goldens cannot prove the rendered workflow runs. The input's semantics were verified against the pinned action's source, but the loop fully closes only when a rendered pnpm/yarn workflow runs on a real repo (one-life will do this naturally on its next re-render).

Verdict: ready to land.