ChromaManager: log operator-actionable error before boot-time Chroma config throw

Context

This ticket was originally filed when Memory Core had a resolveChromaCoordinates(aiConfig) branch for chromaUnified=true && !engines.kb.chroma. That exact path is no longer current.

Live V-B-A on 2026-05-25 shows current Memory Core Chroma boot wiring is:

• ai/services/memory-core/managers/ChromaManager.mjs imports ai/mcp/server/memory-core/config.mjs and logger.mjs.
• ChromaManager.construct() currently destructures const {host, port} = aiConfig.engines.chroma before constructing new ChromaClient({host, port, ssl: false}).
• resolveChromaCoordinates is no longer present in the current Memory Core manager.
• Deployment-wide Chroma coordinates now live at top-level AiConfig.engines.chroma and flow into the Memory Core server template.

The original intent remains valid: malformed or missing boot-time Chroma config should produce an operator-actionable log line before the server dies or constructs a broken client. This is still a cloud-deployment readiness issue because MCP stdio subprocess failures often surface to operators as server-unavailable rather than a clear config diagnosis.

The Problem

Current ChromaManager.construct() assumes aiConfig.engines.chroma exists and contains usable host and port values. If that config is missing or malformed, the failure path is not normalized through the Memory Core logger before boot aborts.

The old prescription is stale, but the passive-observability goal is still correct.

The Fix

Keep the change inside the ChromaManager class surface, not as a module-level helper. Add a small class/private method or inline block that validates the current aiConfig.engines.chroma.{host, port} shape before constructing ChromaClient.

The error message should be single-sourced between logger.error(...) and the thrown Error so logs and exceptions cannot drift.

Acceptance Criteria

• ChromaManager.construct() emits logger.error with an actionable message before throwing when aiConfig.engines.chroma is missing or malformed.
• The log line and thrown Error share one message string.
• Validation stays inside the ChromaManager class/file pattern; no module-level helper function is introduced.
• Test coverage asserts the logger is invoked on the current misconfig path.
• Current stale references to resolveChromaCoordinates are removed or corrected where they describe current behavior.

Out of Scope

• Restoring the old resolveChromaCoordinates API.
• Reintroducing federated engines.kb.chroma routing for Memory Core.
• Soft-fallback from bad Chroma config to another topology.
• A generalized boot-time validation framework.

Avoided Traps

• Do not replace the fail-fast throw with log-only behavior.
• Do not add module-level functions to Neo class files for this narrow validation; keep the behavior on the owning class.
• Do not route this through healthcheck-only logic; this ticket is specifically about passive boot-time observability.