[wefio]

Why

Three incidents had the same unanswered question - is this build talking to the endpoint I think it is - and every time it was answered by inferring from latency. /admin/status now answers it directly.

What it reports

field	why
embedding.endpoint	scheme, host and path - never the key. Read from the client the requests use, so it cannot drift from what is in effect
embedding.{provider, model, dimensions, profile, index_id}	the vector space actually in use
embedding.{timeout_ms, document_timeout_ms, query_budget_ms, write_budget_ms}	the four numbers that bound a request
revision	which build is answering
memory	already present; now next to the rest
failures.summary	counts by code and by route. Reading twenty entries to answer "what is failing" is what made those incidents slow

Failure entries also carry embedding_host and embedding_model, so an old incident can be told apart by configuration instead of by timestamp.

Cost change: shared failure history is opt-in

It cost two bucket round trips per failure - a read and a CAS write on one shared key - paid exactly when the service is already in trouble. The platform log carries the same entry for free and is where incidents are actually read, so persistence now requires NMG_ERROR_HISTORY=1. /admin/status reports which scope it is looking at (isolate_only by default).

Verification

• onlion npm run verify: 36 PASS.
• New assertions: /admin/status is owner-only (401 without the owner identity), reports endpoint/model/index identity/timings/memory shape, never echoes the key, and reports the configured-endpoint case where a provider is stubbed.
• eslint clean.