feat(dashboard): add runtime systems view

[PhilipJohnBasile]

Scope

Provider-neutral Systems tab backed by GET /v1/mtplx/systems, extracted from #336. Includes generic capability/status cards, typed API and polling, navigation, keyboard routing and raw nested-contract inspection. An absent endpoint is reported without disrupting the rest of the dashboard. The UI does not configure or control runtime systems.

Current readiness

Head 34b8678660753522df36a6592184c5e711c324f0 is integrated with exact upstream 21be78b3f51820eecef020e5e4855c0715eaf9a5 through a normal merge. Seven dashboard source files differ from main; no generated static assets are included.

#362 now supplies a concrete read-only serving-status provider from existing runtime counters. This resolves the previous absence of a useful first provider at the source-integration level. That backend remains a separate dependency; this PR does not duplicate it.

Readiness run 34069355260, macOS ARM64 / Python 3.11 / Node 22:

• 421 serving/dashboard/import-boundary tests passed, zero failures/errors/skips.
• Frozen dependency installation and production dashboard build passed, completing in 2.65 seconds. This is a build receipt, not a paired performance benchmark.
• Python compilation and diff checks passed.
• Generated assets were restored after testing, with the source-only diff asserted before creating the candidate commit.
• The exact tested merge was fast-forwarded to the branch. Audit workflows/helpers remain fork-only.

Ready for coordinated source review with #362 and #364. Maintainer acceptance, release ordering and a packaged product smoke remain distinct; this description does not claim a browser-to-physical-model end-to-end run.

Historical measurement

The earlier build reported +7,188 raw / +1,714 gzip bytes for the Systems UI. Those values belong to the prior measured source and are not presented as a new comparison for this integrated head.

Excluded: runtime control, policy hooks, replay, memory governance, request capture, model/expert systems and generated assets.

[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 Addressed the generated-assets request in b8d1516. The static subtree now matches the merge-base exactly; the PR contains seven dashboard source files and no rebuilt assets. The release build owns bundle regeneration.

The description preserves the earlier measurements as prior results rather than claiming a new run. Ready for source review. The requirement for a real provider publishing useful status through #362 remains a shipping gate; this cleanup does not turn an empty registry into a completed integration.

[PhilipJohnBasile]

Current-main readiness update: 34b8678 includes 21be78b. All 421 serving/dashboard/import-boundary tests and the production build passed before publication. The diff remains seven source files, with no generated static assets. Receipt: https://github.com/PhilipJohnBasile/MTPLX/actions/runs/34069355260 .

The first-provider dependency is now implemented in #362 as read-only serving status from existing counters. It preserves runtime ownership and authentication. Ready for coordinated source review; the actual provider remains in #362 rather than duplicated here.