watcher: continuous auto-sync re-indexing churn on Windows (real driver of #832)

[DeusData]

During the #833 review we found the reported 20GB RSS / 100% CPU / 600MB-per-minute growth on 65 markdown files (1.3MB) cannot be produced by a single index run — the reporter's own workaround (CBM_WORKERS=1 plus auto_index false) points at the auto-sync loop re-indexing continuously on Windows and leaking per cycle.

To investigate:

• Why does the watcher consider an unchanged directory dirty every poll on Windows (mtime granularity? path-normalization mismatch in the git-status hash? CRLF)?
• Per-cycle retention: what survives repeated index cycles (candidate: mimalloc page_reclaim_on_free=0 stranding pages of exited worker heaps — see fix: memory not released after indexing (20GB+ RSS for 5MB data) #833's one plausible line).
  Reproduction should loop N watcher cycles on an unchanged fixture on windows-latest and assert RSS returns to baseline after cbm_mem_collect.

Refs #832, #833.

[DeusData]

v0.9.0 includes Windows watcher/runtime and memory-retention fixes that may change this continuous auto-sync churn path, and #832 is now awaiting a reporter retest on the same class of symptom. Could you retest the unchanged-directory watcher loop on v0.9.0 and confirm whether it still re-indexes continuously? Marking awaiting-reporter.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.