feat(server): add runtime systems status registry

[PhilipJohnBasile]

Summary

Adds the provider-neutral, bounded runtime status registry and read-only GET /v1/mtplx/systems endpoint, extracted from #336. Includes a concrete serving-status provider, so the endpoint is no longer an empty registry awaiting its first producer.

Review head: 8d3aa08f39d7d9a778f0f6dccc88014355240f32, integrated with upstream 21be78b3f51820eecef020e5e4855c0715eaf9a5 through a normal merge.

First provider and ownership boundary

mtplx/server/runtime_status.py reads existing CPU-side server state when the authenticated endpoint is queried: loaded/released availability, AR/MTP mode, active foreground/dashboard counts, completed/cancelled counts, and MTP-enabled status. It reports unavailable/unknown/idle/busy phases; unavailable counters remain null rather than fabricated zeroes.

The provider is wired by production create_app, not a test-only insertion. It has no worker thread and never acquires the model lock, loads a model, calls the Metal allocator, changes configuration, resizes a cache, or owns the runtime budget. The generic registry does not import the serving adapter. Existing owners remain authoritative.

Only bounded scalar counters, fixed enums and booleans cross the boundary. Paths, credentials, client IDs, prompts and exception text are excluded. Failed refreshes replace prior healthy status with a fixed unavailable reason instead of exposing stale success. Collection/publication is serialized; the registry returns detached JSON. Counters are explicitly an aggregate sample, not a transactional multi-counter snapshot.

Validation

Readiness run 34069355260, macOS ARM64 / Python 3.11:

• 436 tests passed, zero failures/errors/skips across registry/provider, actual server route, authentication, serving/dashboard and import boundaries.
• Eight new provider tests cover lifecycle transitions, real create_app wiring, unauthenticated rejection before refresh, counter changes, failed-refresh recovery, redaction, concurrent bounded publication, released runtime and no-MLX import behavior.
• Ruff, formatting, Python compilation and diff checks passed.
• The exact tested merge candidate was fast-forwarded to this PR branch. No audit helpers/workflows or generated dashboard assets are included.

The production route tests inject runtime state; they do not claim a physical-model or packaged-desktop smoke. The new source integration meets the first-provider requirement without inventing a placeholder or second controller.

Review and dependencies

Ready for coordinated source review with #364/#365. Both dashboard branches have also been integrated with the same upstream baseline and their production builds tested, with static assets left to the release build. Maintainer acceptance and release ordering remain separate from source readiness.

Not included: memory governance, replay, expert systems, telemetry export, policy hooks or dashboard implementation. The existing standalone registry benchmark remains a historical control-path measurement, not an inference-performance claim. Provider details are documented in docs/runtime-systems.md.

[youssofal]

Thanks for splitting these out cleanly. As a set they are read-only and low risk, and the registry is the piece the other two depend on. They will be reviewed together for the next release once there is a first component that publishes into GET /v1/mtplx/systems. An empty registry with a tab over it is not something I want to ship before that.

One request for then: leave the rebuilt dashboard assets out of the PRs and let the release build regenerate them, so the diff is source only. Not in 2.11.2.

[PhilipJohnBasile]

@youssofal The source-only cleanup is now pushed to both dependent dashboard PRs: #364 at baeae5e and #365 at b8d1516. Neither includes rebuilt static assets.

Agreed on keeping this registry provider-neutral and waiting to ship the set until a real provider publishes useful status. I have not added a placeholder provider or a second runtime owner just to populate the tab. This PR remains available for coordinated source review with the two dashboard surfaces; the provider/release hold is unchanged.

[PhilipJohnBasile]

@youssofal The first-provider blocker is addressed at 8d3aa08. Production create_app now publishes a read-only serving status from the existing runtime's counters on authenticated endpoint reads. This is not a placeholder or another budget/runtime controller: no model lock, allocator, cache mutation, background polling thread, or configuration ownership is introduced.

The provider reports availability, idle/busy/unknown state, AR/MTP mode and aggregate request counters. Failed reads replace stale healthy data; credentials, paths, client IDs and exception text do not enter the payload. Eight new tests exercise production-route wiring, auth, counter changes, concurrency, failed-refresh recovery and redaction.

Integrated with exact current main 21be78b. The macOS ARM64 selection passed 436 tests with no failures or skips: https://github.com/PhilipJohnBasile/MTPLX/actions/runs/34069355260 . The exact tested merge was fast-forwarded, with audit helpers excluded. #364 and #365 are also on this baseline, with successful production builds and source-only diffs. Ready for coordinated review; the description distinguishes HTTP/runtime-state validation from a physical-model product smoke.