Closes #55. Builds on #54 (toolchain provider → purescript-overlay).

Migrates the test-project toolchain from the legacy Haskell spago (0.21.0, Dhall) to the new PureScript spago (1.0.4, spago.yaml + registry + spago.lock). This is the interim migration that lands the test project; the broader follow-ups (adding spago.yaml to the fork repos, registering pslua as a first-class spago backend, the README backend example) are intentionally out of scope, per the issue's own recommendation.

What changed

• flake.nix — spago-bin.spago-0_21_0 → spago-bin.spago-1_0_4. purs stays 0.15.16, so the compiler that stamps builtWith is unchanged.
• test/ps/spago.yaml (new) — a registry: 77.8.0 baseline (pure, no-FFI packages) plus extraPackages git overrides for every FFI-bearing Lua fork (purescript-lua/purescript-lua-*, current tags), with dependency lists inlined and mirrored from the Lua package set's packages.dhall. This replaces the old upstream-ps // upstream-lua Dhall set where the forks won. No registry set is built for purs 0.15.16, so the baseline uses the latest 0.15.15 set — the same proven-compatible pairing the old Dhall set used.
• No-op backend — backend: { cmd: "true" }. The new spago manages codegen itself and rejects --codegen in --purs-args; declaring a backend is the supported way to make it emit CoreFn (--codegen corefn), which is all the harness needs. This also sidesteps the corefn-staleness bug (spago build didn't update corefn in output directory purescript/spago#643).
• test/ps/spago.lock (new, committed) — pins the resolved fork commits for reproducible golden inputs.
• golden/ → src/ — the new spago only globs src/ and test/, so the golden sources move under src/. The .lua FFI files stay co-located next to each .purs, so the harness's foreign resolution (which searches next to the source file) keeps working.
• Golden/Spec.hs — build command spago build -u '-g corefn' → spago build.
• Docs — CLAUDE.md and docs/GOLDEN_TESTING.md updated for spago.yaml, the new build command, the src/ layout, and PSLUA_GOLDEN_ACCEPT as the safe regeneration path (note: golden_reset destroys the hand-verified eval/golden.txt oracle).

Why PR #41 was incomplete

PR #41 added a spago.yaml but left the sources under golden/, so the new spago compiled zero project modules and the harness silently read stale committed corefn.json. Verified here: without src/, a clean build emits 0 Golden corefn out of 211. Relocating the sources is the fix #41 missed. #41 also used outdated Unisay/* fork URLs (the forks now live under purescript-lua/*) and ignored spago.lock.

Verification

• golden.lua is byte-identical (0 of 52 changed) — the generated Lua is unchanged because the migration preserves the exact same fork versions. Only corefn.json modulePath (golden/ → src/) and golden.ir library paths (.spago/<pkg>/<ver>/ → .spago/p/<pkg>/<commit-hash>/) churn.
• eval/golden.txt oracles are untouched and pass — semantics preserved across the package-set move.
• Full suite green both with PSLUA_GOLDEN_ACCEPT=1 (regeneration) and without it (at-rest, CI-equivalent): 314 examples, 0 failures.