R-361 docs: CONTEXT decision, README, REPORT

Records the db_dumps decision with every consumer named, the trap that a stable
db_dumps lets CaptureRecoveryUnit's already-current early return fire (so
per-capture housekeeping must sit above it), and the NEGATIVE that a held app
does not raise the dead-app alarm - measured, not reasoned, so nobody re-derives
it.

controller/README.md

@@ -571,6 +571,14 @@ Each app can define rich metadata in `.felhom.yml`:
     (they are the undo). The live recovery unit is still never overwritten, which is why the replay
     source is the scratch. Honesty surfaces (`OffsiteScratchPair`): dump age, an unstamped-pair
     warning, and the R-44 empty-dump sniff — all warn-level, none of them gates.
+  - **Where the pre-restore undo copy is written (v0.221.0–.1, R-361).** `DumpOneTo` takes an
+    EXPLICIT final path; `DumpOne` keeps its signature and calls it with the canonical
+    `<stack>-<dbtype>.sql`. The safety dump asks for `pre-restore-<stamp>-…` **directly** — it used to
+    dump to the canonical name and rename afterwards, which destroyed the app's own backup on every
+    restore. The `.tmp` derives from the final path, so a nightly dump and a safety dump in the same
+    directory cannot share a scratch file. `db_dumps` in the manifest lists the app's own dumps only;
+    the undo copies stay on disk and stay visible, capped at 3 per app, pruned from the capture side
+    **above** the already-current early return.
   - **What happens when the database replay FAILS (v0.220.0–.2, R-379/R-380).** A ladder, and every
     rung is observable: **replay → rollback → hold.** The pre-restore undo copy has always been
     taken; since v0.220.0 it is also **put back** when the replay fails — the whole set for this run,