miner-ui(hosted): per-tenant miner health/status strip and chat-groundable health tools

[JSONbored]

Context

Part of the hosted AMS chat platform epic; blocked on the hosted-mode flag sub-issue. #5226 designed fleet-wide health aggregation and a status-page concept for hosted AMS; this issue is the per-tenant product surface: a contributor should see — and be able to ask about — the health of their miner from the dashboard.

Requirements

1. A per-tenant health/status strip in the hosted dashboard: miner run state, last successful manage poll/discover (the unattended-scheduling exit-code contract is the source of truth for "failed run"), active attempts/worktree budget, and queue/claim status.
2. The same signals exposed as chat-groundable tools ("is my miner healthy?", "why did the last discover run fail?") returning the same numbers as the strip — one source, two renderings.
3. Tenant-scoped only: no cross-tenant or fleet-wide aggregates in tenant-facing surfaces; fleet-wide is the operator's view per Design: fleet-wide health aggregation and status-page concept for hosted AMS #5226's design, out of scope here.
4. Failure presentation carries the actionable reason (exit-code contract category, last error line) — not a bare red dot.
5. Health signals degrade defined-ly when the tenant's runtime is unreachable (distinguish "miner stopped" from "telemetry missing").

Deliverables

• The health strip + chat grounding tools, tenant-scoped, feature-flagged off by default.
• Tests: state rendering per signal category, unreachable-vs-stopped distinction, tenant-scoping denial, strip/chat figure equality.

Expected outcome

A hosted contributor never has to shell into anything to answer "is my loop actually running?"

References

Relates to #5226 (fleet-wide design; this is the per-tenant slice).

[linear-code]

JSO-6359