{"error": "Search error: Error executing plan: Internal error: Error finding id"}

Persists ~30-60s, self-heals. During the window:

$ python -m mempalace repair-status
[drawers]
  sqlite count:   1,408
  hnsw count:     (no flushed metadata yet)
  status:         UNKNOWN

CLI search (fresh process) on the same palace works — its freshly-loaded Chroma client opens segments after the
 flush has caught up.

Change

tool_search now wraps its search_memories call with a single retry that:

- detects "Internal error" / "Error finding id" in the result dict via _is_transient_index_error(),
- drops the MCP-local cache and _DEFAULT_BACKEND._clients / _freshness for the palace via
_force_chroma_cache_reset(),
- sleeps 2s,
- retries once,
- tags successful retries with "index_recovered": true so callers can observe when it kicked in.

Non-transient errors (e.g. validation failures) bypass the retry path entirely.

Tests

Three unit tests added to TestSearchTool:

- test_search_retries_once_on_hnsw_flush_transient — first call returns the transient, second succeeds, asserts
 retry ran and index_recovered is set.
- test_search_does_not_retry_on_non_transient_error — unrelated errors propagate without retry.
- test_search_returns_second_error_if_retry_also_fails — persistent transient surfaces the second error rather
than looping.

All 12 tests in TestSearchTool pass locally.

What this does NOT fix

- tool_check_duplicate and other index-touching tools still error in the same window. They'd need the same
wrapper or, better, a shared helper.
- The underlying flush window itself. Options 1-3 from #1315 (auto-flush at end of mine, fail-fast detection,
SQLite-only fallback) are still on the table for a complete fix. This is option 4 — a low-risk recovery wrapper
 alongside, not a replacement.

Refs #1315
Refs #1082

---
Happy to take this in a different direction (e.g. lift the helper into a shared decorator covering all
index-touching tools) if you'd prefer.

---