docs: glossary + ADRs for semantic/concept-graph memory

Captures the design language (CONTEXT.md) and the framing decisions from the
requirements interview: pursue hybrid embeddings+concept-graph retrieval gated
on a benchmark (0001), target the API/Postgres deployment while SQLite stays
lexical (0002), and permit hosted embedding APIs for non-sensitive memories
only (0003). Groundwork for the research/prototype/benchmark effort.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/adr/0002-api-postgres-first-sqlite-stays-lexical.md

@@ -0,0 +1,20 @@
+# API/Postgres deployment gets semantics; SQLite-only stays lexical
+
+The semantic + concept-graph layer targets the **API/Postgres** deployment only: embeddings
+in pgvector on the (CNPG) Postgres, the Concept graph as node/edge tables in Postgres, and
+embedding/extraction via reused cluster infra (llama-cpp on GPU, or a hosted API). The
+**SQLite-only** mode keeps working but stays **lexical (FTS) only** — it gains no embeddings
+or graph, degrading gracefully.
+
+This is surprising because the README markets zero-config offline SQLite as the headline
+feature. We accept that trade-off: the operator actually runs the remote API/Postgres store,
+reuse-before-building favours cluster infra, and bundling a local embedding model into the
+zero-config path would add heavy dependencies and double the build/test matrix for little
+real-world benefit.
+
+## Consequences
+
+- All benchmark numbers are produced in API/Postgres mode.
+- Offline zero-config users see no behaviour change.
+- A future ADR may revisit offline semantics (e.g. via `sqlite-vec` + a small local model)
+  if there is demand.