Add a Runtime Adapter Compute and GPU inventory dashboard

[tiammomo]

Summary

Once the read-only admin inventory API exists, ModelPort needs a focused operator view for understanding which Runtime Adapters are reporting, whether observations are fresh, and how Compute Nodes and GPUs are distributed. This belongs in the dashboard presentation layer rather than in the collector or external adapter contract.

Actual behavior

The dashboard has no Runtime Adapter navigation, freshness summary, node inventory, GPU identity/health/memory view, or accessible empty/stale/error states. Operators must inspect storage or logs and cannot distinguish upstream resource health from snapshot freshness.

Expected behavior

The authenticated dashboard provides a responsive Runtime Adapter inventory page backed only by the ModelPort admin API. It presents adapter freshness, observation time, node and GPU counts, stable identities, vendor/model, device class, health, and memory without exposing control-plane secrets or creating mutation authority.

Steps to reproduce

Open the current ModelPort dashboard after Runtime Adapter snapshots exist; no page or component presents adapter, Compute Node, or GPU inventory.

Environment

ModelPort dashboard after #30, with fresh, stale, unavailable, empty, and multi-adapter admin API responses.

Acceptance criteria

• Add a dedicated Runtime Adapter inventory route and navigation entry using the existing dashboard layout, authentication, API client, and design tokens.
• Present a deterministic adapter summary with fresh/stale/unavailable badges, observed age/time, node count, and GPU count; do not conflate freshness with node or device health.
• Render expandable or detail views for stable node IDs, host labels, architecture/OS, GPU IDs, physical/partition class, parent identity, vendor/model, health, and total/available memory.
• Use only the versioned ModelPort admin API; never call Runtime Adapter origins directly or display origins, credentials, credential environment-variable names, Authorization data, or raw upstream errors.
• Provide bounded refresh behavior with request cancellation and visible last-updated state; avoid overlapping refreshes and preserve the last accepted view during transient failures.
• Handle loading, empty registry, unavailable snapshot, stale snapshot, authorization failure, and recoverable API error states with accessible text rather than color alone.
• Keep tables/cards keyboard accessible and responsive, and add component/API tests for redaction, state rendering, ordering, memory formatting, partitions, and refresh cleanup.
• Update dashboard documentation and screenshots only if repository-native assets are available; exclude generated marketing imagery.
• Exclude adapter mutations, GPU allocation, model deployment controls, provider routing, provider-specific code, and local-inference-stack integration.