testbed: stop destroying the player's save

The documented way to run the testbed began with

    rm -rf ~/AppData/Roaming/LOVE/Alchemist

which is the player's actual playthrough. It was written down as the
official procedure in four places, so every run of the test suite ate a
real save -- including twice in the session that produced the previous
commit. Reported by Talon.

The testbed does genuinely need an empty save directory: it drives a new
game from the main menu through the prologue, which has already happened
in any real save. So tests/run-testbed.sh MOVES the save aside (never
deletes it), runs, discards the test run's directory and moves the real
one back. Restore is on an EXIT trap plus INT/TERM, so it also happens on
a failed run, a crash and Ctrl-C. If the restore itself fails it says so
loudly and leaves the backup on disk rather than pressing on.

This cannot live inside the mod: love.load calls config.initialize,
keybindings.initialize and user.initialize long before main.lua reaches
require("accessibility").initialize(), so by the time any of our Lua runs
the save directory has already been read. The swap has to happen around
the process.

The rm -rf is removed from all four docs that carried it, each replaced
with the script and the reason not to clear that directory by hand --
being written down as procedure is what made it recur.

accessibility/.gitattributes forces LF on *.sh, or a Windows checkout
hands bash a \r and the script dies. It sits inside accessibility/ on
purpose: a top-level one would show up in the game-file footprint check,
which still reads `main.lua | 1 +`.

Verified with a marker file in a populated save directory: 38 checks, 0
failures, marker intact, no leftover backup directories.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

accessibility/docs/00-dev-setup.md

@@ -122,8 +122,7 @@ cd "D:/code/Sulphur Memories Alchemist 0.4.2 sanctified"
 lua accessibility/tests/test_history.lua     # pure Lua, instant
 luac -p accessibility/*.lua                  # syntax only, no LOVE needed
 
-rm -rf ~/AppData/Roaming/LOVE/Alchemist      # clean save
-"C:/Program Files/LOVE/lovec.exe" . --a11y-test          # ~4 min
+bash accessibility/tests/run-testbed.sh      # ~4 min — save-safe, see below
 
 git diff --stat vanilla-0.4.2 -- . ':!accessibility' ':!.gitignore' ':!CLAUDE.md'
 ```
@@ -143,8 +142,29 @@ To just play it:
 ### Save data
 
 LÖVE writes to `~/AppData/Roaming/LOVE/Alchemist` (`t.identity = "Alchemist"` in
-`conf.lua`). Deleting it is how you get a clean prologue; the testbed scenario
-assumes a fresh save and will not navigate correctly without one.
+`conf.lua`). The testbed scenario assumes a fresh save and will not navigate
+correctly without one — it drives a new game from the main menu through the
+prologue, which has already happened in any real save.
+
+**Do not clear that directory by hand.** It holds the player's actual
+playthrough, and `rm -rf` on it — which is what these docs used to say — destroys
+it. Use `accessibility/tests/run-testbed.sh`, which:
+
+1. **Moves** the save to `Alchemist.a11y-backup.<pid>` (never deletes it),
+2. runs the testbed against the empty directory LÖVE then creates,
+3. discards the test run's directory and moves the real save back, from an `EXIT`
+   trap so this happens on failure, on a crashed run and on Ctrl-C too.
+
+If the restore itself ever fails it says so loudly and leaves the backup on disk
+rather than pressing on.
+
+Why a wrapper and not something inside the mod: `love.load` calls
+`config.initialize`, `keybindings.initialize` and `user.initialize` long before
+`main.lua` reaches `require("accessibility").initialize()`. By the time any of
+our Lua runs, the save directory has already been read — the swap has to happen
+around the process.
+
+Override the interpreter path with `LOVE=/path/to/lovec.exe` if yours differs.
 
 Runtime files the game also drops next to the source during dev (`config.json`,
 `user.json`, `keybindings.json`, savegames) are already in `.gitignore`.