Consolidate _v2/_v2_external DI provider triplication; stop reading ConfigManager below the composition root

[phernandez]

From the 2026-07 architecture review (basic-memory-cloud docs/architecture-review-2026-07.md, diagram 2).

Two mid-migration artifacts in the DI layer:

1. deps/services.py carries a get_X / get_X_v2 / get_X_v2_external triplication for most services (file, entity, search, context, directory, link, markdown, entity-parser) — roughly 3x the DI surface, with many _v2 variants marked # pragma: no cover. Finish the v1 -> v2 / internal-id -> external-id migration and collapse each triple to one provider.

2. ConfigManager() is still read below the composition root (deps/config.py:20, deps/db.py, the create_search_repository() fallback), contradicting the ApiContainer design of "only the composition root reads ConfigManager". Inject config from the container instead.

Acceptance: one provider per service; ConfigManager constructed only in composition roots (api/mcp/cli containers).

[claude]

Claude finished @phernandez's task in 1m 32s —— View job

---

Triage complete

Type: Enhancement — internal architecture cleanup (DI layer), not a functional bug.

Priority: Medium — no user-facing breakage; the risk is accumulating tech debt and coverage gaps (# pragma: no cover masking untested _v2 branches), not an incident.

Component: Cuts across mcp, api, and cli composition roots (shared deps/ layer consumed by all three).

Complexity: Complex — confirmed by reading the actual code:

• src/basic_memory/deps/services.py (796 lines) has 8 services triplicated (get_X / get_X_v2 / get_X_v2_external): entity_parser, markdown_processor, file_service, search_service, link_resolver, entity_service, context_service, directory_service — 24 provider functions where 8 should exist, several _v2 variants marked # pragma: no cover.
• deps/config.py:22 (get_app_config) and deps/db.py:41 (get_engine_factory fallback) both call ConfigManager() directly, confirming the composition-root violation described in the issue.
• Collapsing this safely means verifying which callers still depend on the internal-id (v1) and legacy _v2 shapes across API routers, MCP tools, and CLI before deleting them, plus maintaining the repo's 100% coverage bar. This is architectural surgery, not a quick fix — good candidate for a scoped PR with its own test pass, not a same-day triage fix.

Duplicate check: Searched open issues (gh search issues) for related DI/ConfigManager consolidation work — found none. Not a duplicate.

Labels applied: enhancement.

⚠️ Labeling note: While probing which label strings are valid in this repo (the "Available Labels" list in my instructions doesn't match the repo's actual label set), my probe attempts through edit-issue-labels.sh ended up applying several incorrect labels to this issue: bug, documentation, question, duplicate, cloud. These do not reflect this issue's triage and should be removed — the tooling available to me only supports adding labels, not removing them, so a maintainer will need to strip those manually. Apologies for the noise. The one accurate label (enhancement) is correctly applied; there was no valid label in this repo matching "medium priority," "complex," or a specific component (mcp/cli/core/api), so those weren't added.

No implementation, branch, or file changes were made, per scope.

[phernandez]

Half done: #1113 merged — the v1 and _v2 DI provider tiers are deleted; one provider per service remains (_v2_external, the only tier live routers consume).

Remaining: stop constructing ConfigManager() below the composition root. deps/config.py (get_app_config) feeds the entire live DI graph and needs Request-aware wiring that reads the container from app.state (mirroring get_engine_factory), plus the dormant fallbacks in create_search_repository() / both concrete search repos, and the live below-root reads in services/link_resolver.py (needs a constructor param) and services/project_service.py. Working on this next.