Make LM Studio embedding readiness load-aware

Context

Follow-up to closed #13944. That ticket covered the silent LM Studio embedding context truncation class. The current live validation found a different but adjacent gap: embedding model enumeration/residency is not enough to prove the embedding endpoint can safely serve work, and manual or daemon canaries can become unsafe when they run concurrently with real orchestrator / KB sync activity.

Release classification: boardless local Agent OS runtime-safety hardening; promote only if operator marks it as a deployment closeout gate.

Live latest-open sweep: checked latest 20 open issues at 2026-06-24T12:27:09Z; no equivalent open ticket found. Closest related tickets are #13944 (closed, context truncation), #13948 (provider role-set residency), #13700 (LM Studio chat parallel memory), and #13539 (closed, duplicate embedding instances). A2A in-flight sweep over latest 30 messages at 2026-06-24T12:27:09Z returned no competing claim.

The Problem

After the orchestrator/harness restart, local LM Studio showed the configured chat and embedding models resident. Live evidence then split into three important facts:

• lms ps --json reports the chat model as contextLength: 131072, parallel: 1, but the embedding model as contextLength: 32768, parallel: null.
• A tiny /v1/embeddings canary succeeds when the orchestrator is stopped and models are idle (200, vector length 4096), and the embedding model remains resident afterward.
• A prior direct large synthetic embedding probe, run while orchestrator/KB activity could also use LM Studio, caused severe local memory pressure and a provider/socket failure. This must not become the daemon reproduction path.

So the runtime gap is not just "is the model listed" and not just "is context high enough". The serving proof itself must be bounded, serialized, and load-aware. Otherwise a diagnostic canary can create the exact outage pressure it is supposed to detect.

The Architectural Reality

• ai/services/graph/providerReadinessHelper.mjs currently uses lms ps --json metadata for loaded context / parallel readiness.
• LM Studio appears not to report embedding parallel through lms ps --json (parallel: null), even when the UI can show a parallel value. Treating null !== AiConfig.localModels.embedding.parallel as an unsatisfied gate can produce an impossible recovery loop.
• TextEmbeddingService is the actual Memory Core / KB embedding consumer. Readiness that only checks /v1/models or loaded-model metadata can still miss endpoint-serving failures.
• ADR-0019 applies: config values such as localModels.embedding.contextLimitTokens and localModels.embedding.parallel must be resolved leaves read at the use site; the fix must not add hidden defaults, type coercion, env rereads, or config pass-through.

The Fix

1. Keep enforcing LM Studio embedding context from the resolved AiConfig.localModels.embedding.contextLimitTokens leaf.
2. Do not turn an unobservable embedding parallel: null telemetry value into an unsatisfiable post-load readiness gate. Chat parallel should remain enforced where LM Studio reports it.
3. Add a tiny embedding-serving canary only behind a bounded, serialized, load-aware path. It must not run during active heavy maintenance / KB sync contention and must not use large synthetic inputs.
4. Classify Model unloaded, socket close, timeout, or canary failure as explicit degraded embedding-serving readiness with operator-actionable diagnostics, not as proof that /v1/models residency is sufficient.
5. Ensure diagnostics report the observed model id, context length, parallel observability state, canary status, and whether the canary was skipped due to load.

Contract Ledger Matrix

Decision Record impact

Aligned with ADR-0019 and ADR-0025. This ticket does not amend either ADR; it tightens provider-readiness evidence and prevents diagnostics from becoming a resource-pressure source.

Acceptance Criteria

• LM Studio embedding rows with parallel: null do not fail post-load readiness solely because AiConfig.localModels.embedding.parallel is numeric.
• Chat model parallel remains enforced when LM Studio reports a numeric chat parallel value.
• Embedding context remains enforced against AiConfig.localModels.embedding.contextLimitTokens.
• A tiny embedding-serving canary can be run only through a bounded serialized path and reports success without logging vector bodies.
• The canary is skipped or degraded, not executed, when load/backpressure indicates active heavy maintenance or embedding contention.
• Model unloaded, socket close, timeout, and non-2xx canary responses produce explicit diagnostics instead of being hidden behind /v1/models success.
• Unit coverage proves the parallel:null embedding case, canary-success case, and canary-failure/degraded case.
• No live or automated large-input embedding stress probe is required for validation.
• No ADR-0019 regressions: no hidden defaults, no runtime env rereads, no type coercion wrappers, no config subtree pass-through.

Out of Scope

• Raising or lowering the default embedding context cap from #13944.
• Reproducing memory pressure with large live embedding inputs.
• Tenant-repo parser/chunking work.
• Native Ollama request-shape fixes from #13946.
• Duplicate LM Studio embedding instance diagnostics from #13539.
• Adding public privileged MCP tools or shell/socket access.

Avoided Traps

• Do not use /health as an LM Studio readiness endpoint; live logs show it is unsupported noise.
• Do not treat /v1/models as proof that /v1/embeddings can safely serve.
• Do not run large synthetic embedding canaries in daemon loops.
• Do not equate unknown embedding parallel telemetry with failed config enforcement.
• Do not bypass orchestrator/backpressure by adding ad-hoc direct provider probes.

Related

Related: #13944, #13948, #13700, #13539, #13914, #13936, ADR-0019, ADR-0025.

Handoff Retrieval Hints: LM Studio embedding readiness parallel null tiny canary Model unloaded socket close memory pressure, lms ps embedding parallel null v1 embeddings serving proof load-aware canary