feat: hook-based knowledge backend registry + backend contract doc (depends on #280)

[esafwan]

Depends on #280

This PR builds directly on #280 (feat/pgvector-knowledge-doctypes) and is intentionally based on that branch — do not merge before #280 lands. After #280 merges to develop, this PR's base should be retargeted to develop.

What this adds

1. huf_knowledge_backends hook + dynamic registry — replaces the hardcoded backend dict in huf/ai/knowledge/backends/__init__.py::get_backend() with hook-based discovery, mirroring the existing huf_tools pattern. External Frappe apps can now register their own knowledge backend:

   # external app's hooks.py
   huf_knowledge_backends = {"qdrant": "my_app.knowledge.qdrant_backend.QdrantBackend"}

   Validation: registered classes must subclass KnowledgeBackend; collisions with built-in type keys are logged and skipped (external apps cannot shadow built-ins).

2. BACKEND_CONTRACT.md — documents the backend contract and the two sanctioned implementation paths:

   • subclass LlamaIndexBackend (added in feat: add PGVector knowledge source #280) for stores LlamaIndex supports — recommended, ~50–100 lines per backend;
   • implement KnowledgeBackend directly for portable/unsupported stores (the sqlite_vec exception).
     Also covers: embeddings stay HUF-side, core connection fields vs advanced_config tuning params, and the live-test bar for new backends.

3. Tests — test_backend_registry.py: hook merging, collision handling, subclass validation (mocked frappe.get_hooks), run green in-bench.

Why

Audited across all knowledge backends: the hardcoded registry was the single blocker to external-app pluggability. This unlocks the standardization plan the historical vector-store PRs (#234, #235, #236, #238, #149, #168, #230, #231, #232) are being re-scoped against — each carries a TODO comment pointing here.

🤖 Generated with Claude Code