fix(memory/holographic): track retrieval counts across retriever paths

[BongSuCHOI]

Summary

Fixes #17899.

Holographic memory exposes retrieval_count, but the production retrieval paths used by prefetch() and fact_store returned facts without incrementing that usage counter. MemoryStore.search_facts() had inline counter logic, but the tool/provider paths go through FactRetriever.search(), probe(), related(), reason(), and _score_facts_by_vector() instead.

This PR moves the counter update into a shared store helper and records retrievals for every fact list returned by the retriever.

Changes

• Add MemoryStore.mark_retrieved() as the single helper for retrieval_count updates.
• Reuse that helper from the existing search_facts() path.
• Record returned facts in:
  • FactRetriever.search()
  • FactRetriever.probe()
  • FactRetriever.related()
  • FactRetriever.reason()
  • _score_facts_by_vector()
• Keep counter updates advisory: a bookkeeping failure does not break memory lookup.
• Add regression coverage for keyword and structural retrieval paths.

Related prior work

I searched existing issues/PRs first. Two closed PRs had addressed the same bug class:

• fix(memory): increment retrieval_count in retrieval.search() (#17899) #17910 fixed only search().
• fix(memory/holographic): track retrieval_count on all retrieval methods #21022 covered the broader retriever surface but is closed and not merged.

This PR reintroduces the broad fix with focused tests against current main.

Testing

python -m pytest tests/plugins/memory/test_holographic_retrieval_count.py tests/plugins/memory/test_holographic_shutdown_closes_db.py -q
# 6 passed

python -m pytest tests/agent/test_memory_provider.py tests/plugins/memory/test_holographic_retrieval_count.py -q
# 104 passed

python -m py_compile plugins/memory/holographic/store.py plugins/memory/holographic/retrieval.py tests/plugins/memory/test_holographic_retrieval_count.py
git diff --check

[alt-glitch]

This was generated by AI during triage.

Related to the narrower open PR #39664 (increments retrieval_count only in FactRetriever.search()) and issue #17899. This PR is the broader fix covering all retriever paths (search/probe/related/reason/_score_facts_by_vector) via a shared mark_retrieved() helper — subset/superset, not a duplicate. Flagging the cluster for a maintainer to pick.

[BongSuCHOI]

Thanks for triaging. Yes, this PR intentionally covers the broader retriever surface via the shared mark_retrieved() helper, while #39664 only covers the search() path.

[teknium1]

Verified that the counter gap remains on current main: prefetch() and fact_store route through FactRetriever, whose result paths return without changing retrieval_count (plugins/memory/holographic/retrieval.py:106-112, 189-190, 257-258, 335-336, 478-479; plugins/memory/holographic/__init__.py:206-210, 284-318). The shared helper is a good fit, and current main's shared store lock is re-entrant (plugins/memory/holographic/store.py:153).

Problems

• The new structural parametrization does not exercise _score_facts_by_vector(): its probe case has no category (tests/plugins/memory/test_holographic_retrieval_count.py:66), but that helper is reached only through the category-bank branch (plugins/memory/holographic/retrieval.py:139-152).

Suggested changes

• Add a categorized probe regression and assert the returned fact IDs increment, covering the category-bank/vector route.

Automated hermes-sweeper review.

[teknium1]

This probe case has no category, so it takes probe's direct scoring path rather than the category-bank branch that calls _score_facts_by_vector() (retrieval.py:139-152). Please add a categorized probe assertion so the new bookkeeping in that helper has regression coverage.