feat(learn): consolidation layer + RDF-inspired entities/relationships graph

[ashu17706]

Summary

Started as the Continuous Knowledge Consolidation Layer and grew a second piece: an RDF-inspired entities/relationships graph on top of it, after discussing how RDF's triple model (subject-predicate-object, canonical resource identity, typed vocabularies) could strengthen the self-learning loop.

Part 1 — Continuous Knowledge Consolidation (Progressive Summarization): cheap Stage-1 extraction (segmentSession) runs broadly over dense sessions into a new smriti_knowledge_units table; expensive Stage-2 polish (generateDocument) only runs once a unit proves it's reused (recalled repeatedly) or scored high relevance at extraction time.

• src/db.ts — smriti_knowledge_units table + CRUD helpers (insertKnowledgeUnit, findUnsegmentedDenseSessions, findPromotableUnits, incrementRetrievalCount, promoteKnowledgeUnit, listKnowledgeUnits)
• src/search/recall.ts — tracks retrieval_count on every recall() exit path
• src/learn/consolidate.ts — segment phase + promote phase
• src/index.ts, src/format.ts — smriti consolidate and smriti learnings

Part 2 — Entities & relationships graph (RDF-inspired, not literal RDF — no URIs/SPARQL, just typed (subject_type, subject_id) pairs in SQLite): today's entities: string[] field is write-only — never queried or matched, so "JWT" in one session and "JSON Web Token" in another look unrelated. This closes that gap and also persists what ollamaCheckConflicts previously only computed ephemerally.

• src/db.ts — smriti_entities (canonical registry) + smriti_relationships (triple store) tables; new minEntityReach promotion criterion — a unit becomes promotable once its entity is independently mentioned by K other units, even at 0 retrievals
• src/learn/entities.ts — resolveEntity (exact-normalize canonicalization via slugify), insertRelationship/getRelationships (triple store), findRelatedCandidates, findEntity, getUnitsForEntity
• src/learn/consolidate.ts — segment phase turns Stage-1 entities into mentions edges for free (no extra LLM calls); promote phase adds one bounded LLM call (only when entity-sharing candidates exist) to infer relatesTo/supersedes/contradicts edges
• Team/org propagation — an entity's canonical id is only meaningful if every teammate's machine agrees on it. src/team/config.ts/share.ts/sync.ts route entities through the exact same .smriti/config.json git round-trip custom categories already use (exportEntities/mergeEntities mirror exportCustomCategories/mergeCategories). Unit-to-unit relationship edges propagate via frontmatter directly — no canonicalization needed there, since unit ids are already portable UUIDs once shared.
• src/index.ts, src/format.ts — smriti graph <entity> command, --min-entity-reach flag on consolidate

Two pre-existing bugs found and fixed while building the propagation tests (both predate this PR, exposed because nothing previously tested a real share→sync round trip on disk):

• syncTeamKnowledge's agent fallback used "team" as an agent id that was never seeded into smriti_agents, so importing any shared file without an explicit agent field (true for the entire pre-existing segmented pipeline) hit an FK violation. Fixed by seeding a team agent.
• syncTeamKnowledge only recognized pipeline === "segmented" as a single-message document; pipeline === "consolidated" docs were misparsed as raw transcripts and silently skipped on import.

Both remain CLI-only, never wired into the daemon — same reasoning as enrich: LLM work per-flush is unsafe (see src/daemon/index.ts's enrichOnIngest comment).

Test plan

• test/learn-consolidate.test.ts — segment-phase dedup, promotion threshold, graceful degradation, retrieval tracking
• test/learn-entities.test.ts — entity canonicalization (exact-normalize merge, no false-merge on real synonyms), relationship triple insert/dedup/pattern-lookup, mentions edges from segment phase (zero extra LLM calls), minEntityReach promotion, LLM-inferred relationship edges (+ best-effort failure handling), findRelatedCandidates
• test/learn-entities-sync.test.ts — two independent in-memory DBs standing in for two teammates' machines, connected only through a shared tmp .smriti/ directory: confirms an entity converges to the same canonical id via share→sync (not an independently re-slugified duplicate), and that supersedes edges between shared units survive the round-trip
• bun test --cwd ./test — 391 pass, 0 fail across 33 files, no regressions
• Manual smoke test: smriti consolidate, smriti learnings, smriti graph <entity> run cleanly against a fresh DB