feat: Add BackendFactory and enhanced KnowledgeBackend ABC

[esafwan]

Summary

Implements BackendFactory pattern and enhances KnowledgeBackend ABC for multi-backend support.

Changes

• BackendFactory - Registry-based factory with connection pooling and site-aware caching
• Enhanced ABC - Added health_check(), supports_filters(), supports_hybrid_search() methods
• Auto-registration - Backends auto-register on module load
• Updated backends - SQLite backends implement new interface methods

Factory Features

• Site-scoped instance caching
• Health check aggregation
• Cache management utilities

Related

Enables pluggable vector database backends (pgvector, Chroma, Redis, etc.).

[esafwan]

Status update: largely superseded by PR #280 + PR #406

Since this PR was opened, the direction it explored has been adopted through other work:

• The enhanced KnowledgeBackend ABC now exists on the PR #280 branch, including get_advanced_config_schema() and a shared LlamaIndexBackend base class (backends/llamaindex_base.py).
• The registry/factory idea has been implemented as a hook-based dynamic registry (huf_knowledge_backends, mirroring the huf_tools pattern) in PR #406 (depends on feat: add PGVector knowledge source #280), including hook discovery, subclass validation, collision handling, tests, and a BACKEND_CONTRACT.md. The BackendFactory + auto-registration-at-module-load design in this PR (huf/ai/knowledge/backends/factory.py) is not the chosen direction.

What remains salvageable from this PR

The capability methods (health_check, supports_filters, supports_hybrid_search) are still valuable and align with the cross-backend standardization plan (capability flags on the contract):

• Port the capability methods to the ABC as non-abstract defaults (e.g. health_check returns (True, "Not implemented"), filters/hybrid default to False) so existing backends aren't forced to implement them — target this at the feat: hook-based knowledge backend registry + backend contract doc (depends on #280) #406 branch or a follow-up on top of it.
• Update sqlite_fts.py and sqlite_vec_backend.py to provide real capability values.
• Drop factory.py and the auto-registration block — superseded by feat: hook-based knowledge backend registry + backend contract doc (depends on #280) #406's hook registry.

Once the capability-flag port is done (or deliberately deferred), this PR can be closed with a pointer to #280/#406.

[esafwan]

Closing as stale / re-scoped.

The knowledge-backend architecture has standardised on the #280 → #406 → #434 line: LlamaIndexBackend base class (#280), the huf_knowledge_backends hook registry + BACKEND_CONTRACT.md (#406), and hook-registered backends (#434). This PR predates that line: it targets the hardcoded get_backend() registry, carries the ~5k-line PRD/planning doc bundle, and conflicts with the contract's config model (advanced_config schemas vs separate settings DocTypes).

A backend from this PR can be revived as a small contract-compliant implementation (see huf/ai/knowledge/backends/BACKEND_CONTRACT.md on develop after #280/#406 merge): subclass LlamaIndexBackend (~50–100 lines) or implement KnowledgeBackend directly, register via huf_knowledge_backends in the owning app's hooks.py, expose tuning via get_advanced_config_schema(), and pass the live-test bar. The Redis backend in #434 is the reference implementation.