ADR: allow memory to be served by an external backend

[nicwn]

Adds an ADR proposing a seam for external memory backends: adrs/external-memory-backend.md.

Today memory is one markdown notebook per scope, with the backend fixed in wiring.ts (Postgres when DATABASE_URL is set, else a file workspace) and no turn-lifecycle hooks on the chassis plugin surface. A deployment that wants to reuse an existing layered/vector memory system has no integration point short of forking core.

The ADR keeps the built-in notebook as the zero-config default and asks for the project's direction between two shapes:

• a pluggable MemoryService via config (MEMORY_BACKEND=http) delegating to an HTTP sidecar — minimal, but recall's markdown-body return forces a layered backend to flatten its atoms/persona into one block; and
• a turn-lifecycle hook (a memory provider returning structured recall the orchestrator renders, plus onTurnEnd for capture) with the notebook as the built-in provider — more surface, but preserves a layered backend's tiers.

Seeking a decision on whether to take either, both behind one config, or neither. No code yet; implementation follows whichever direction the project prefers.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}