fix(memory/holographic): wire retrieval_count into all retrieval paths via locked store helper

[ar-nim]

What does this PR do?

Fixes a dead-code bug where retrieval_count was permanently zero for all facts.

The plugin has two FTS5 search paths. They were written in the same commit (924bc67, PR #4623). They were never connected to each other.

• store.search_facts() has the retrieval_count increment. It has zero callers.
• FactRetriever.search() uses _fts_candidates(). It is the active path used by prefetch and fact_store(search). It does not call the increment.

retrieval.py was ported from a separate codebase ("KIK memory_agent.py" per its docstring) with its own FTS5 pipeline, duplicating the store-level search without inheriting the counter. The same gap existed in probe(), related(), and reason() — they also returned facts without recording retrievals.

The fix adds MemoryStore.increment_retrieval_count() under the shared self._lock and calls it from all 5 retrieval paths. Writing _conn directly would bypass MemoryStore's shared connection contract (one connection + one RLock for serialized access across coexisting provider instances). The helper centralizes the counter SQL so every caller uses the same serialized path.

After increment, each result dict is bumped by 1 so the response matches the DB (was always one behind — read 0 from DB, incremented DB to 1, returned 0).

Related Issue

N/A — small bug fix with clear root cause documented above.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• plugins/memory/holographic/store.py — Add MemoryStore.increment_retrieval_count() under the shared re-entrant self._lock. Reuse from search_facts() to eliminate duplicated SQL.
• plugins/memory/holographic/retrieval.py — Call the locked helper from all 5 paths: search(), probe(), related(), reason(), and _score_facts_by_vector(). Bump each result dict after increment so response matches DB.
• tests/plugins/memory/test_holographic_retrieval.py — 6 new tests: keyword search, accumulation, structural paths (probe, related, reason) with entity-bound facts, selectivity (non-returned facts stay at 0), and dict-DB consistency.

How to Test

1. Run the full test suite: pytest tests/plugins/memory/test_holographic_retrieval.py -v
2. Verify all 16 tests pass

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, test(scope):)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (6 new tests, 16 total)
• I've tested on my platform: Linux (openSUSE Leap 16 / Arch Linux)

Documentation & Housekeeping

• I've updated relevant documentation (docstrings) — or N/A
• I've updated cli-config.yaml.example — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md — or N/A
• I've considered cross-platform impact — or N/A
• I've updated tool descriptions — or N/A

Screenshots / Logs

pytest tests/plugins/memory/test_holographic_retrieval.py -v
============================== 16 passed in 0.69s ==============================

[teknium1]

Thanks for tracing this through the active provider paths. On current main, FactRetriever.search() calls _fts_candidates() at plugins/memory/holographic/retrieval.py:65 and returns results at :106-112 without updating retrieval_count; the existing update is confined to the separate MemoryStore.search_facts() implementation at plugins/memory/holographic/store.py:280-287. The live prefetch and fact_store actions call the retriever directly at plugins/memory/holographic/__init__.py:204-208 and :285-319.

The PR's locked helper and coverage for keyword and structural result paths fit the existing shared-connection design. The target files are unchanged on current main since the PR base, and GitHub reports the branch mergeable.

Automated hermes-sweeper review.