docs/RECOVERY.md is the one page a person reads at 3 a.m., and a test keeps it true to src/snapshot #1480

Split from #1219 (a person's ask). Both tries went red on the gate's list check. A new test file was not listed in scripts/gate.ts, and main's own list was red then too (0.7.75 fixed that). This half is the document only.

Done looks like.

• [ ] docs/RECOVERY.md fits on one printed side and covers:

- where snapshots live (bucket, prefix, region); - the variables a restore needs (S3_ENDPOINT S3_BUCKET S3_REGION S3_ACCESS_KEY S3_SECRET_KEY), plus FORGE_SNAPSHOT_PASSPHRASE, which is kept in the owner's safe; - the one restore command, exactly as src/snapshot/restore.ts prints it (bun run src/snapshot/restore.ts <snapshot-name> <empty data dir>); - how to boot the forge on that directory on a side port, and what to look at first: /api/v1/health, the home as the owner, and one repository's issues; - what a snapshot does NOT hold: sealed values, app variables and the crew's clones.

• [ ] A second route: the manual tarball under manual/<stamp>/ in the same bucket, opened with openssl enc -d -aes-256-cbc -pbkdf2 -pass file:<passphrase> and then untarred. The doc says when to prefer it.
• [ ] test/recovery-doc.test.ts fails when the doc misses any variable src/snapshot/store.ts reads, or when its restore command differs from the one src/snapshot/restore.ts prints.
• [ ] test/recovery-doc.test.ts is named in GATE in scripts/gate.ts. Before the pull, bun test test/recovery-doc.test.ts test/check-list.test.ts passes in the sandbox, and the pull says so.

Evidence. #1147's comments from 2026-10-13. Files. docs/RECOVERY.md (new), test/recovery-doc.test.ts (new), scripts/gate.ts. Fits: scout.