swarm.js: drop the queue-summary banner rather than ship it on an interim jobq fetch

mara, on the already-approved PR: "dont replace one legacy thing with
another. then we will have to either wait with this pr or split it
into what can and cannot be done now."

Splitting: the transients-only per-agent badge fix is real, correct,
and fixes a live regression (the old DagView fields it read no longer
exist) — nothing about it depends on job-queue data at all, so it
ships as-is. The queue-summary banner is the part that doesn't belong
in this shape: it was reading GET /api/jobq/graph directly and
deriving counts client-side as an interim stand-in for the dedicated
rollup endpoint mara separately asked for — exactly the kind of
stopgap-on-a-stopgap her comment is calling out, since the endpoint
that should serve it doesn't exist on main yet.

Removes jobqNodesState, refreshJobqGraph(), the rebuild_queue_changed
SSE subscription, and the banner's render block from swarm.js/tabs.js
entirely — swarm.js now reads no job-queue state of any kind, fully
satisfying "swarm.js should not need to pull in the jobq to do its
job." The banner comes back once the rollup endpoint
(hyperhive#2985's follow-up) exists, reading that directly instead of
the full graph. Until then the per-agent transient pills still show
what's actually running on each card; only the hive-wide "N running /
M queued" summary line is temporarily gone.

CSS classes for the banner (.queue-summary/.queue-summary-link) kept
in dashboard.css rather than deleted-then-restored — commented as
currently unused, expected to come back unchanged.

docs/web-ui/dashboard.md updated to match (Container-row pending-
badge section, the removed Build-queue-summary-banner section, and
the BU1LDS-page note that used to describe SW4RM's now-removed
parallel fetch).

docs/web-ui/dashboard.md

@@ -209,10 +209,12 @@ Three sub-tabs: **R3BU1LD QU3U3** (default), **M3T4 1NPUTS**,
 **BUILD L0GS**. Its own esbuild bundle (`builds.js`); cold-loads
 `/api/state` and subscribes to `/api/dashboard/stream` for
 `rebuild_queue_changed`, `meta_inputs_changed`, `meta_update_running`.
-The SW4RM tab (`/dashboard.html`) independently self-fetches the same
-`GET /api/jobq/graph` endpoint for its own card badges + queue-summary
-banner (`refreshJobqGraph`, `swarm.js`) — same data source, no panel
-rendering, no shared fetch between the two pages.
+The SW4RM tab (`/dashboard.html`) does **not** read this endpoint (or
+any job-queue state) at all — mara, on review: "swarm.js should not
+need to pull in the jobq to do its job." Its per-agent pending badges
+are transient-only, and its queue-summary banner is removed for now
+(see Container row, below), pending a dedicated rollup endpoint it
+can read directly instead of the full graph.
 
 **R3BU1LD QU3U3** — pending, in-flight, and recently-settled container
 operations: rebuilds, meta-update cascades, and first-spawns. One
@@ -913,14 +915,16 @@ fetch entirely.
   their own label directly via `TransientSet`/`TransientCleared`
   events carrying no backing node at all.
 
-  **Queued (not-yet-started) work shows nothing on the card.** An
-  earlier version of this page had a job-queue-backed fallback badge
-  for the `Pending` case (`queuedOpsByAgent()` in swarm.js, reading
-  `jobqNodesState`); removed per mara, on review of hyperhive#3028's
-  PR: *"swarm.js should not need to pull in the jobq to do its job"*,
-  followed by *"remove the per agent pending stuff - only show what
-  is running."* `jobqNodesState` still exists in swarm.js, but now
-  feeds only the queue-summary banner below, not per-card badges.
+  **Queued (not-yet-started) work shows nothing on the card, and
+  `swarm.js` reads no job-queue state at all.** An earlier version of
+  this page had a job-queue-backed fallback badge for the `Pending`
+  case (`queuedOpsByAgent()`, reading a `GET /api/jobq/graph` fetch);
+  removed per mara, on review of hyperhive#3028's PR: *"swarm.js
+  should not need to pull in the jobq to do its job,"* followed by
+  *"remove the per agent pending stuff - only show what is running."*
+  The queue-summary banner below was, for the same reason, also pulled
+  rather than kept on that same client-side graph-fetch — see its own
+  entry below for why.
   An **active model badge** (`model · <name>`, blue) appears when the
   container is running and the harness has persisted a model name
   (`harness/hyperhive-model`). Read by hive-c0re's `ContainerView`
@@ -961,19 +965,23 @@ per-agent actions and navigation links. Contents:
 agent is stale. Banner pulses on each broker SSE event
 (`pulseBanner` with a 4s grace timer).
 
-**Build-queue summary banner** — when `jobqNodesState` has any
-`Pending` / `Running`(-or-`Finishing`) **group roots** (`parent:
-null` — each an independent queued/running operation, not a raw
-node count: a multi-step op's not-yet-started sub-steps don't inflate
-the number), a compact amber banner sits above the container list:
-`◐ build queue — N running · M queued — view queue →` (the link goes
-to the BU1LDS page's R3BU1LD QU3U3). A root's own `state` already
-carries its subtree's roll-up (`hive-jobq-wire`'s contract), so this
-is a direct filter over `jobqNodesState`, not a client-side rollup
-derivation. It replaces the old per-transient spinner list; the
-actual running node for each agent is already shown on its card
-(transient + in-flight-queue badges), so the top of the tab only
-needs the at-a-glance summary.
+**Build-queue summary banner — currently removed, coming back on a
+different data source.** Previously a compact amber banner above the
+container list (`◐ build queue — N running · M queued — view
+queue →`, linking to the BU1LDS page), derived client-side from `GET
+/api/jobq/graph` (filter to `parent: null` group roots — each an
+independent operation, not a raw node count — bucket by `state`).
+Pulled per mara, on review of hyperhive#3028's PR: *"dont replace one
+legacy thing with another. then we will have to either wait with
+this pr or split it into what can and cannot be done now"* — a
+client-side derivation over the generic graph was itself judged a
+stopgap not worth landing, the same way the old `DagView` read it
+replaced was. Comes back once a dedicated rollup endpoint (status ×
+count pairs, tracked separately) exists for `swarm.js` to read
+directly instead of pulling the whole graph in for a summary. Until
+then, the actual running work per agent is still visible on each
+card via the transient pills; only the hive-wide at-a-glance count is
+missing.
 
 ### Themed dialogs