P2 slice 7: backups and restore (D-30, D-31)

The server backs each book up itself: a per-book git archive, pushed
fast-forward only to a git remote and to a folder, when the books open,
after a quiet spell, before they close and on request; every commit,
push and drill is a record in ops/backup.jsonl. Drills clone each
target and verify the chain, the blobs, the vault and the head, weekly
and after a failure. `wanderbooks books restore` previews, then
restores beside or (with --replace) over, never moving books something
holds. The archive refuses anything but a plain bare repository and
pins git against the owner's configuration. books.backup and
books.back_up_now for the agent.

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

docs/receipt-store.md

@@ -27,10 +27,13 @@ easily backupable, journable":
   bytes to `journal.jsonl.torn.<time>`, truncates to the last newline, and
   journals a `journal.tail_repaired` line; `books.digest` reports it.
   Damage before the last newline is corruption and refuses to open: that
-  is for a human, never repaired automatically. Better: the journal is
-  git-friendly, so an optional `wanderbooks backup` that commits it to a
-  private git repo gives versioned, distributed, deduplicated backup with
-  full history.
+  is for a human, never repaired automatically. The server does better
+  (plan 3.7): it commits the journal, the blobs, the vault, its key and
+  the access log to each book's own git repository (the blobs staged
+  ahead, the commit under the store's lock) and pushes it to the
+  owner's private repository and backup folder, versioned and
+  deduplicated, with full history (docs/mcp-interface.md, "Tools —
+  backups").
 - **Journable.** It literally is a journal: `{seq, ts, type, payload, prev}`.
   Greppable, diffable, replayable. The audit trail isn't a feature bolted
   on — it's the storage format.
@@ -76,8 +79,9 @@ is correct: the journal records what happened, including abandoned work.
 `wanderbooks verify` (a `ledger-store` API, later a CLI subcommand):
 re-read the journal, recompute the hash chain, replay every line into a fresh
 in-memory `Ledger`, and compare its reports against the SQLite projection's.
-Any mismatch is a loud failure. Run it on startup (cheap at this scale) and
-before backups.
+Any mismatch is a loud failure. Run it on startup (cheap at this scale);
+a backup is then proven where it lands, by a drill (docs/mcp-interface.md,
+"Tools — backups").
 
 ## Blob store