feat(ops): show worker and queue readiness

docs/SCALABILITY_PROFILES.md

@@ -40,6 +40,11 @@ The Ops API reports:
   stale state, and drain state
 - configured versus active API and worker replica counts
 - active worker-pool names, exact queue coverage, and missing queue owners
+- provider-neutral worker state (`disabled`, `unconfigured`, `starting`,
+  `healthy`, `idle`, `busy`, `degraded`, `stale`, or `unreachable`), with the
+  configured backend, latest heartbeat age, and stale threshold
+- queue depth, active/reserved work, and failure count only when reported by
+  the provider; unavailable values are never interpreted as zero or healthy
 - release/module-composition skew and software-version skew across active nodes
 - rendered PostgreSQL connection peak, declared server limit, and operator reserve
 - recovery operation status, mode, checkpoint count, and last update
@@ -90,6 +95,15 @@ states. S3 capacity remains provider-owned unless a configured module check
 supplies bounded usage metrics; Ops must not enumerate an object store merely to
 render a dashboard.
 
+The WebUI polls this read-only projection every 15 seconds only while its page
+is visible. It permits one request at a time, stops the timer when the document
+is hidden, and performs one refresh when visibility returns. Runtime providers
+register through the Core contract; Ops itself does not import Celery, Redis,
+or module-owned job implementations. A local development profile may
+intentionally disable workers without becoming unready. A production or other
+non-development profile treats a disabled, unconfigured, stale, or unreachable
+provider as readiness-critical.
+
 Promote from a single-process profile to a split-worker profile when queued
 work becomes part of normal operation: