feat(bridge): keep a step's teardown with its key — teardownOf (D385)

Core records nothing for a step that failed or whose answer was lost, and
then reverts it with only the key: no server, no teardown. So a run request
now carries its `teardown`, stored in the key's record and never run with
it, and `{ key, teardownOf }` runs the teardown stored under `teardownOf`,
under its own key, at most once:

- only when something there may have run (some commands ran, or a reload
  cut the run off); otherwise answered with nothing run and nothing kept;
- `busy` while the run it is for is still going;
- a reward carries no teardown (refused `malformed`), and a teardown takes
  no placeholders.

Re-compiled and driven on both rigs (a failed run's teardown ran once, a
repeat ran nothing, nothing-ran and unknown keys ran nothing); rigs
restored to the protocol-13 bridge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

README.md

@@ -143,7 +143,9 @@ recipient of a reward who is online, with `{steamid}` and `{name}` filled in (th
 argument). That is how a plugin with no support of its own here is used from an event, for example
 RaidableBases' `rbe`. There is no allowlist: the site's switchboard is the switch, and `EventsEnabled`
 here is the server's. Each request runs at most once: its key is written to
-`data/RunicGateway/commands-run.json` before anything runs, and is kept for seven days. A command the
+`data/RunicGateway/commands-run.json` before anything runs, and is kept for seven days. A step's
+teardown commands are kept with its key too, so the site can have them run even for a step that failed
+part-way or whose answer was lost (`teardownOf`). A command the
 server does not know stops the request there as `unknown-command`. On a framework with
 `consolePlugins=False`, that is every plugin's command.