loopd: the memory block from memoryd, recall and memory as core tools

Implemented-By: OpenCode session (model recorded in docs/implementer-log.md)

docs/runbook.md

@@ -395,7 +395,7 @@ by something other than `loopd`. Start a new session and keep the old log for in
 **Check.** The next turn on the session succeeds. The first request re-reads the conversation if
 the cache was lost, which `loopd` logs as a cache loss.
 
-## core-memory-unreadable
+## memory-unavailable
 
 **What you see.** Starting a new session fails with an error naming `memory/core.md`, and this
 entry. Existing sessions still work: they use the baseline saved when they started.
@@ -635,3 +635,27 @@ listening elsewhere, or is stuck.
 `[sockets] broker` in `memoryd.toml` name the same path.
 
 **Check.** Ask the agent to recall something; the answer lists hits or says there were none.
+
+## memory-index-damaged
+
+**What you see.** `memoryd` exits 1 at start with `index: <reason>` naming its index file, then
+this entry.
+
+**Why.** The index is the fast path to memory. If `memoryd` cannot read it, it does not know what
+it has stored, so it stops rather than guess. A missing file is a first start and is fine.
+
+**Confirm.**
+
+```sh
+ls -l "$BOXMAKER_HOME/index/memory.sqlite3"
+python3 -c 'import sqlite3; sqlite3.connect("<path>").execute("SELECT count(*) FROM sqlite_master")'
+```
+
+**Fix.** Move it aside and start `memoryd`, which rebuilds it:
+
+```sh
+mv "$BOXMAKER_HOME/index/memory.sqlite3" "$BOXMAKER_HOME/index/memory.sqlite3.damaged"
+memoryd serve --config <path>
+```
+
+**Check.** `memoryd serve --config <path>` prints `memoryd: serving`, and a `recall` call answers.