Context: #55 introduced a no-op backend: { cmd: "true" } to make Spago emit CoreFn, and that is now how test/ps and every migrated fork build. Separately, purescript-lua-package-sets now publishes a consumable packages.json (a RemotePackageSet: the registry baseline with the Lua forks overlaid as git entries), which projects consume via workspace.packageSet.url. The remaining gap for downstream users is making pslua itself a first-class Spago backend, so spago build targets Lua out of the box instead of the no-op true plus a hand-run pslua step.

Scope:

• Verify the pslua CLI matches Spago's backend contract: Spago compiles to CoreFn, then invokes <workspace.backend.cmd> <args>. Confirm pslua reads the corefn from output/, foreign from --foreign-path, and emits via --lua-output-file / --entry when invoked that way; fill any gaps (argument mapping for spago build / spago run, multi-module output).
• Update README.md to the new spago.yaml form: workspace.packageSet.url pointing at a published Lua set plus the workspace.backend for pslua, replacing the legacy spago.dhall backend snippet (this folds in the README doc fix). Update CLAUDE.md if relevant.
• Update purescript-lua/purescript-lua-template and the example repo to the new spago: a spago.yaml with workspace.packageSet.url (the published set) and workspace.backend for pslua, dropping spago.dhall / packages.dhall.

Acceptance: a fresh project from the template builds Lua via spago build against the published set with pslua as the backend; README shows the new spago.yaml.