Tooling to promote a golden/ change back into templates/

The prototype-in-`golden/`-then-hand-port-to-`templates/` loop is entirely manual, including restoring the `[PROJECT-NAME]` token wherever the concrete `golden-app` module path appears in Go imports. The golden-app design left automation as a non-goal on the grounds that diffs are expected to be small, and said to revisit if it became a real pain point (`docs/superpowers/specs/2026-08-28-golden-app-runnable-tree-design.md`, *Non-goals (YAGNI)*).

Registering it so the pain is tracked rather than re-litigated each time. The mechanical part — diffing `golden/` against a fresh `Copy()` and re-tokenising the module path — is well defined; whether it is worth building depends on how often the port actually goes wrong.

Came out of reviewing the deferred sections of the existing specs.

Read docs/superpowers/specs/2026-08-28-golden-app-runnable-tree-design.md, especially the deferred automation and YAGNI sections. Inspect the existing Copy() entry point and compare golden/ with a fresh copy to understand the proposed diff and [PROJECT-NAME] re-tokenisation. Done means establishing whether the porting errors justify tooling and defining the scope if they do.

Written by the indexing model from the issue text.