[infra-dashboard] Fix stale comment about Connect RPC JSON support

All Connect RPC methods support JSON natively via POST + Content-Type
application/json — the old comment claiming /health was "the only
easily-callable JSON endpoint" was wrong since we added the SQL-backed
panels. Addressed PR review feedback from rjpower.

Author: ravwojdyla

infra/status-page/README.md

@@ -228,9 +228,9 @@ break** — we'll need to plumb a service-account bearer token.
      so history lives authoritatively next to the workers table.
 - **Iris panel reachability row** is still `/health`-only. Worker counts
   and job-state breakdowns are surfaced in the Workers and Jobs
-  subsections; tasks / autoscaler / detailed state are still behind the
-  full Connect RPC surface and would need generated TypeScript stubs
-  (or more `ExecuteRawQuery` SQL).
+  subsections via `ExecuteRawQuery` SQL. Tasks, autoscaler, and detailed
+  state are available via other Connect RPC methods (all support JSON
+  natively) but would need additional SQL or direct RPC calls wired up.
 - **Single cluster only** (`marin`). Extending to `marin-dev` means
   adding a second Cloud Run service or making the existing one
   multi-cluster.

infra/status-page/server/sources/iris.ts

@@ -1,11 +1,10 @@
-// Iris controller reachability.
+// Iris controller reachability via the /health endpoint.
 //
-// In v1, the controller's only easily-callable JSON endpoint is /health
-// (see lib/iris/src/iris/cluster/controller/dashboard.py:396). Everything
-// else is HTML dashboard or Connect RPC. This source reports reachability
-// + round-trip latency and leaves room in the response shape for richer
-// data later (which is increasingly supplied by the workers and jobs
-// sources reading the controller's SQLite directly via ExecuteRawQuery).
+// All Connect RPC methods on the controller support JSON natively
+// (POST + Content-Type: application/json), which is how the workers
+// and jobs sources call ExecuteRawQuery. This source sticks with the
+// simpler /health GET because it only needs a binary reachable/latency
+// signal, not structured data from the controller's SQLite.
 
 import { getControllerUrl } from "./discovery.js";