fix: add threading lock to LRU cache to prevent data corruption under concurrent load (#562)

[ionfwsrijan]

Description

The in-memory LRU cache (_lru_get/_lru_set) uses bare dict and list with zero synchronization. Four distinct race conditions exist:

1. _lru_set — _lru_order.remove(key): Two threads both find key in _lru_store is True. Thread A calls remove(key) successfully. Thread B calls remove(key) on the already-removed key → ValueError: list.remove(x): x not in list.
2. Eviction race: Two threads both find len(_lru_store) >= LRU_MAX_SIZE. Both pop from _lru_order and delete from _lru_store — eviction is corrupted.
3. Check-then-set non-atomicity: Two threads both check if key in _lru_store, both find it absent, both append to _lru_order — duplicate entries.
4. Partial-write read in _lru_get: While one thread is mid-json.dumps(vector), another reads partially-written JSON → json.JSONDecodeError.

Changes

backend/app/cache.py

• Added import threading
• Added module-level _lru_lock = threading.Lock()
• Wrapped _lru_get, _lru_set, and _lru_delete with with _lru_lock: to make all LRU cache operations atomic and thread-safe.

Impact

• Eliminates intermittent ValueError and json.JSONDecodeError under concurrent load
• Prevents stale/partially-written cache entries that could cause semantically incorrect RAG retrieval
• Affects both document ingestion (embed_texts) and user queries (embed_query)

Closes #562

[ionfwsrijan]

@param20h Please review this