HealthService: surface effective unified/federated topology in /health

Context

Surfaced during #10001 self-review (PR #10121) and re-flagged on #10007 self-review (PR #10123). Now that the unified-topology pillar of sub-epic #10015 is complete (#10001 routing + #10007 lifecycle bypass, both merged), operators deploying Memory Core in unified mode need a way to verify the flag resolved as expected without inspecting logs or re-running the config through node -e.

The Problem

Today's HealthService.healthcheck() returns {engines: {chroma: true}} — a binary reachability flag. It does not expose:

• The effective topology (unified / federated)
• The effective ChromaDB coordinates the client is targeting ({host, port})
• Which config path won the resolution (engines.chroma vs engines.kb.chroma)

Operators running curl .../healthcheck in a cloud container have no in-band way to confirm they set NEO_CHROMA_UNIFIED=true correctly and that the client is pointed at the KB's instance. A misconfiguration where chromaUnified is forgotten would be silent: MC would spin up its own ChromaDB (federated path), mount a distinct volume, and populate a distinct collection set — diverging from the KB's state without any operator-visible signal until cross-tenant drift emerges.

The Architectural Reality

The information to surface already lives in-process, thanks to #10001 and #10007:

• aiConfig.chromaUnified — the flag itself
• ChromaManager.resolveChromaCoordinates(aiConfig) — returns the effective {host, port} per topology (extracted as a pure method in #10001 specifically to make this kind of aggregation possible without singleton re-instantiation)
• ai/mcp/server/memory-core/services/HealthService.mjs — the existing healthcheck implementation

The fix is pure aggregation — no new resolution logic, no config duplication.

Proposed response shape:

{
  "status": "healthy",
  "database": {
    "connection": {"connected": true, "collections": {...}},
    "topology": {
      "mode": "unified",
      "coordinates": {"host": "localhost", "port": 8000},
      "resolvedVia": "engines.kb.chroma"
    }
  }
}

resolvedVia names the config key path that won the resolution — operator gets a direct pointer to what to check if coordinates look wrong.

The Fix

1. Extend HealthService.healthcheck() to call ChromaManager.resolveChromaCoordinates(aiConfig) and include the resolution under database.topology.
2. Add a Playwright spec at test/playwright/unit/ai/mcp/server/memory-core/services/HealthService.spec.mjs (new file) asserting:
   • topology.mode === 'federated' when chromaUnified=false
   • topology.mode === 'unified' when chromaUnified=true
   • coordinates matches aiConfig.engines.chroma / aiConfig.engines.kb.chroma respectively
   • resolvedVia names the correct config key path
3. Update learn/agentos/MemoryCore.md to document the new /health topology fields (can absorb the deferred doc pass from #10001 + #10007).

Acceptance Criteria

• healthcheck MCP tool response includes database.topology with {mode, coordinates, resolvedVia} fields.
• Federated-mode response shows mode: 'federated', coordinates matching engines.chroma, resolvedVia: 'engines.chroma'.
• Unified-mode response shows mode: 'unified', coordinates matching engines.kb.chroma, resolvedVia: 'engines.kb.chroma'.
• New HealthService.spec.mjs covers both topology branches.
• learn/agentos/MemoryCore.md documents the new fields.

Out of Scope

• Changing the flag resolution logic itself — only the reporting surface. ChromaManager.resolveChromaCoordinates is the single source of truth and stays unchanged.
• Adding topology reporting for non-ChromaDB subsystems (SQLite graph path, inference provider, embedding provider). Those are separate follow-up tickets if the pattern proves valuable.

Related

• Closes the follow-up commitment from PR #10121 (#10001) and PR #10123 (#10007)
• Consumes ChromaManager.resolveChromaCoordinates(aiConfig) extracted in #10001
• Unblocks operator-facing diagnostics for sub-epic #10015 deployments

Origin Session ID: 1c001810-be28-4554-bb56-c98f9b91bbfb