Support incremental knowledge base updates

[mgoltzsche]

Currently the add_documents method drops all collections before recreating them and importing the documents. This requires all documents to be provided to the add_documents method whenever calling it which makes the update latency grow with the amount of documents.

Instead, it would be great if there would be a way to update the knowledge base incrementally.

[zc277584121]

The first version of incremental knowledge base updates has landed in #37. It adds document-level upsert_documents() and delete_documents() APIs, keeps the existing add_* methods as deprecated full-rebuild wrappers, and introduces explicit rebuild_* APIs for full refreshes.

This covers the basic create/replace/delete flow for one source document without rebuilding unrelated documents. Follow-up work should be tracked separately for production-scale storage design, especially explicit document_id / tenant_id fields, indexing or partition-key strategy, entity/relation ID strategy, and stronger consistency guarantees around multi-step cascade updates.

[zc277584121]

Incremental knowledge-base updates are now supported through source-level APIs:

• upsert_documents_by_source(...) creates or replaces the chunks and graph references for one source without rebuilding unrelated sources.
• delete_documents_by_source(...) removes one source and cleans up graph references that only belong to that source.
• The legacy add_* APIs keep their full-rebuild behavior for compatibility, while the explicit rebuild_* APIs should be used for intentional full refreshes.

Docs:

• https://zilliztech.github.io/vector-graph-rag/incremental-updates/
• https://zilliztech.github.io/vector-graph-rag/python-api/#upsert_documents_by_source

The current implementation is source-level and retryable rather than transactionally atomic. If an update is interrupted, rerunning the same upsert/delete for that source is the recommended recovery path.