swarm.js: restore the queue-summary banner on GET /api/jobq/rollup

hyperhive#3033 (jobq rollup endpoint) merged, unblocking hyperhive#3036.

The banner (removed on PR#3031 rather than ship it on an interim
GET /api/jobq/graph client-side derivation) is back, now reading
GET /api/jobq/rollup — hive-jobq-wire::state_rollup's pre-tallied
Vec<StateCount>, not the full graph. running sums the Running and
Finishing entries' roots (Finishing = own work done, subtree still
going); queued reads the Pending entry's roots. roots specifically,
matching the banner's established "N whole operations" meaning, not
the endpoint's parallel nodes count (~7 nodes per rebuild, 1 root).

Re-adds the rebuild_queue_changed SSE subscription dropped alongside
the banner, wired as a payload-less refetch trigger — confirmed with
atlas on the DagView-deletion tracker that this is the intended final
shape (keep the event, drop the payload) rather than deleting it and
falling back to polling.

Verified the running/queued derivation against constructed
StateCount[] fixtures (running+queued mix, Finishing-counts-as-running,
settled states never contribute, multi-state sums) before touching
swarm.js — 6/6 checks passed. npm run build clean, tracker-tag +
comment-block pre-push lints clean. docs/web-ui/dashboard.md updated
to describe the restored banner + the two prior shapes it went
through.

docs/web-ui/dashboard.md

@@ -209,12 +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`) 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.
+The SW4RM tab (`/dashboard.html`) does **not** read this endpoint 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 reads the much narrower `GET /api/jobq/rollup`
+instead (see Container row, below) — a handful of pre-tallied counts,
+not the graph.
 
 **R3BU1LD QU3U3** — pending, in-flight, and recently-settled container
 operations: rebuilds, meta-update cascades, and first-spawns. One
@@ -915,16 +915,15 @@ 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, 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.
+  **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()`, 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."* Per-agent badges never came back — only
+  the queue-summary banner below did, once a narrow enough endpoint
+  existed for it to read instead of the full graph.
   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`
@@ -965,23 +964,28 @@ 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 — 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.
+**Build-queue summary banner** — when the job queue has any active
+work, 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). Reads `GET /api/jobq/rollup`
+(`hive-jobq-wire::state_rollup`, `jobqRollupState` in `swarm.js`) —
+`Vec<{ state, nodes, roots }>`, every lifecycle state present in a
+fixed order, zero counts included — rather than the full
+`/api/jobq/graph` tree: `running` sums the `Running` and `Finishing`
+entries' `roots` (`Finishing` = own work done, subtree still going,
+still in flight), `queued` reads the `Pending` entry's `roots`.
+`roots` specifically, not `nodes` — the banner has always meant *N
+whole operations*, not raw steps (one rebuild is ~7 nodes but 1
+root); `nodes` exists on the same endpoint for a consumer that wants
+step-level counts instead, unused here.
+
+This banner went through two prior shapes before landing here, both
+per mara review comments on hyperhive#3028's PR: a client-side
+derivation over the full graph (*"swarm.js should not need to pull in
+the jobq to do its job"*), then removed entirely rather than keep
+that interim fetch (*"dont replace one legacy thing with another"*).
+Restored once the dedicated rollup endpoint (hyperhive#3033) existed
+for it to read directly instead.
 
 ### Themed dialogs