Persistent knowledge base: dedicated Knowledge node schema + extraction pipeline + knowledge_search/add/forget tools

## Summary

LM2's auto-injection (Phase 4: `symbol_context`/`get_doc_context` auto-inject) and confidence decay (Phase 3) are already implemented and working. What's missing is a dedicated, queryable knowledge layer on top of them: a real `Knowledge` node type in the graph, a pipeline to extract facts from saved sessions, and MCP tools to search/add/forget knowledge directly rather than relying purely on incidental auto-injection.

Three categories of knowledge (from design discussion): **codebase** facts (e.g. "this module intentionally duplicates X because Y"), **interaction** facts (user preferences, workflow quirks), and **decision** facts (architectural choices and their rationale — similar in spirit to what `save_session`'s `decisions` field captures today, but queryable independently of any one session).

## Design decisions (from prior design session)

- **Storage:** graph nodes in the existing Kuzu+Cozo DBs, not a separate store. Rationale: infigraph already has graph infrastructure, and knowledge naturally links to existing `Symbol`/`File` nodes (e.g. a knowledge fact about "why this function is structured this way" should be an edge from a `Knowledge` node to the relevant `Symbol` node).
- **Confidence model:** starts at 0.7 on extraction. User-corrected facts jump to 1.0. Decays 0.05/week if unused. Re-confirmed usage resets to 0.9. Anything that decays below 0.3 gets archived (not deleted).
- **Retrieval:** two paths — (1) auto-inject into `symbol_context`/`get_doc_context` responses (zero-effort, facts appear alongside code context automatically), and (2) a dedicated `knowledge_search` tool for explicit queries.
- **Scope for v1:** project-scoped, not team-shared. A sync/sharing layer is an explicit non-goal until v1 proves out.
- **Scale assumption:** designed around ~10K max facts per project. If that's insufficient in practice, needs pruning or tiered storage — not designed yet.

## Open question (blocking, needs a decision before implementation)

**Extraction approach is undecided**: rule-based, LLM-assisted, or hybrid. Suggested path: start rule-based (extract from `save_session`'s structured `decisions`/`constraints`/`assumptions` fields, which are already semi-structured), and layer in LLM-assisted extraction from free-text `narrative` later if rule-based proves too shallow.

## Scope (proposed, not yet built)

1. `Knowledge` node schema in Kuzu + Cozo (with a `HAS_KNOWLEDGE` edge type linking to `Symbol`/`File` nodes).
2. Extraction pipeline: turn saved session data into `Knowledge` nodes (approach per the open question above).
3. New MCP tools: `knowledge_search`, `knowledge_add`, `knowledge_forget`.
4. Confidence decay job (weekly, per the model above).

## Related work already shipped

LM2 Phases 3 (confidence decay) and 4 (auto-injection + selective indexing) are already implemented — this issue is specifically about the parts that were designed but not yet built: the dedicated node schema, the extraction pipeline, and the explicit query/mutation tools.

Start by reading the existing save_session, symbol_context, and get_doc_context entry points, then trace how graph data is stored in the Kuzu and Cozo databases. The extraction approach is still undecided, so implementation cannot begin until rule-based, LLM-assisted, or hybrid extraction is selected; done would include the proposed Knowledge schema, extraction pipeline, MCP tools, and confidence-decay job.

Written by the indexing model from the issue text.