feat(foundryvtt-plugin): promote the cargo-generate template to default and retire scaffold.py

[laurigates]

Tracking issue for the second half of the #2205 pilot. Do not start this until the exit criterion below is met — the pilot deliberately shipped both generators with scaffold.py as the default.

Exit criterion

The template has generated at least one real FoundryVTT module repo end to end — scaffolded, bun install, just check green, pushed, release-please wired, module loads in Foundry.

Byte-identical parity against scaffold.py across all three variants is already proven mechanically (test-template-parity.sh, 9/9). What is not proven is that anyone has lived with the cargo-generate flow for a real module: the install step, the --define ergonomics, the prompts when values are omitted, whether the Rhai pre-hook's kebab-case handling is pleasant in practice.

Blocked on

• fix(ci): test-template-parity.sh never runs in CI — cargo-generate absent and templates/ not a path trigger #2221 — the parity test does not currently run in CI. Retiring scaffold.py while the only thing proving equivalence is a local-only test would be backwards.

When the criterion is met

1. Flip the default in foundryvtt-module-scaffold/SKILL.md — template first, scaffold.py as the documented fallback.
2. Delete scaffold.py (1,279 lines) once no skill references it.
3. test-template-parity.sh loses its comparison half and becomes a template-only smoke test — generate each variant, assert the tree shape and that module.json parses. Keep it; the variants are still worth pinning.
4. Update foundryvtt-plugin/README.md and templates/README.md (both currently say "scaffold.py remains the default" in as many words).
5. cargo install cargo-generate --locked becomes a hard prerequisite of the skill rather than an alternative path — state it in the skill's requirements, not a footnote.

If the criterion is not met

Deleting the template is a perfectly good outcome. The pilot's value was answering the question; a negative answer is an answer. The cost of keeping both indefinitely is the parity test plus the cargo-generate dependency, and that is not free.

The most likely reason for a negative result is the toolchain cost: requiring a Rust toolchain (or a release-binary install) to scaffold a TypeScript repo is the one genuinely awkward part of the port, and it is the thing to weigh hardest.

Related

• feat(rust-plugin): add cargo-generate skill and foundryvtt template pilot #2205 — the pilot
• fix(ci): test-template-parity.sh never runs in CI — cargo-generate absent and templates/ not a path trigger #2221 — CI enforcement of the parity claim (blocker)
• feat(comfyui-plugin): evaluate porting comfyui-node-scaffold (3,045 lines) to cargo-generate #2224 — the comfyui port, which is gated on this one paying off
• foundryvtt-plugin/templates/README.md — comparison, divergences, brace-collision fixes