docs(receipt): OKF/ontology is unused on every branch — removal inventory and work order

Andy asked (2026-09-10) whether OKF is used and, if the data says it serves no
purpose, for it to be removed ahead of a semantic layer. This receipt is the
verification, not the removal.

Verified from source and the live database: main has no OKF/ontology code; on
the three feature branches (PR #18's tree is byte-identical to
origin/feat/b4-recall-surfaces) it is ~5,300 source lines that no serving path
reads -- every consumer is a writer, a diagnostic or a snapshot-stripper, and
mcp_server.py's own docstring says "No embedding or ontology store". The value
gate written for it (G3b) was never reached; the claim-centric layer it fed
scored 0.129 against a 0.64 bar and 0 of 2,033 imported OKF concepts were ever
citation-bound. All 66,324 live ontology_* rows were produced by a deterministic
builder (hashlib/re/sqlite3 only) and are rebuildable at $0.

Two things the removal must respect: PR #18 splits 13 drop / 14 keep, and the
keep-half contains fb33e2c -- the AND-to-OR query planner, the programme's one
established win -- so the resolution is merge the keep-half, drop the OKF half;
and context_concepts holds one non-derived row (a wind-down Finding) that must be
exported as prose before any DROP. The DROP list is recorded but gated on Andy's
explicit confirmation with a verified .bak first: this database is the only
surviving copy of ~89% of session history.

Author: NetDevAutomate