fix: isolate bm-local runs from the operator's personal Basic Memory config

[groksrc]

Summary

The bm-local provider runs basic-memory CLI commands and the warm MCP stdio server with the operator's own Basic Memory config (~/.config/basic-memory or equivalent). Two failure modes observed while running fresh benchmarks on a machine with a cloud-mode setup:

1. Cloud routing kills the provider. With a cloud-mode config, search_notes resolves workspaces through cloud.basicmemory.com; an expired JWT turns every query into 401 Unauthorized and bm-local errors out of the run.
2. BM sync mutates the benchmark repo. A configured project with an empty path resolves to the process cwd, so the spawned MCP server synced the benchmark repo itself and injected Basic Memory frontmatter (title/type/permalink) into README.md, AGENTS.md, docs/benchmarks.md, and dataset READMEs.

Changes

• Build an isolated environment in ingest(): BASIC_MEMORY_CONFIG_DIR=benchmarks/bm-home/ (gitignored), which scopes config, project registry, SQLite index, and fastembed cache to a benchmark-owned directory — the exact isolation hook BM provides for per-process state
• Pass that env through run_command (new optional env param) for all bm CLI calls
• Pass it explicitly to StdioServerParameters — the MCP SDK only forwards a small safelisted environment to stdio servers by default, so setting vars in the parent process is not enough

Fairness / reproducibility impact

Strictly improves reproducibility: runs no longer depend on (or mutate) whatever Basic Memory state the operator happens to have. No change to query handling, scoring, or provider configuration. First run on a fresh bm-home downloads the embedding model into the isolated cache once.

Validation

• uv run ruff check . and uv run pytest tests pass
• Full LoCoMo run (1,986 queries) on a cloud-mode machine completed with bm-local state ok (previously errored with the JWT failure), and the repo's markdown files stayed clean

🤖 Generated with Claude Code