job_queue: retire the now-off-wire step sub-step label

The `step` label was taken off the wire in #2661, when each deploy phase
became a first-class DAG node. Since then it has been written but never
read: `NodeRuntime` derives only `Debug, Default, Clone` — no serde — so
the field could not reach any client, and the only reads of it were the
dedup checks inside its own setters. This deletes the machinery.

Removed:

- `NodeRuntime.step`, `set_step`, `set_step_running`, and the
  `rt.step = None` clear in `complete_node`. `NodeRuntime` keeps its
  remaining `build_log_id` field (deliberately still a struct — collapsing
  it to a bare `Option<i64>` would churn every call site for no gain).
- `Ctx::step` and its ~15 call sites in `job_queue/exec.rs`. `Ctx` itself
  stays: it is the build-log sink, which `run_prebuild` and `run_swap`
  still use.
- `Coordinator::set_queue_step` and its 11 callers in `actions.rs`.
- `JobQueue::running_node_of`, reachable only from `set_queue_step`.
- `swap_update`'s `on_step` parameter and its one body call.
- The `set_step_only_on_running_and_signals_change` test.

Dropping the calls orphaned parameters, which are removed with their call
sites: `ctx` on ten executors that used it only as a step sink, and
`queue_entry_id` on `run_deploy_merge_verify` / `run_deploy_apply` /
`run_finalize_deploy` plus both `coord` and `queue_entry_id` on
`prepare_applied_target`. `run_deploy_tail` KEEPS its `queue_entry_id` —
that one has a genuine surviving use (the build-log link in the failure
comment posted to the PR).

One behavioural change, called out so it is not mistaken for a dropped
dashboard refresh: `Ctx::step` and `set_queue_step` each emitted a
`rebuild_queue_changed` snapshot when the label changed, and those
emissions go away with them. This is safe — the snapshot payload has no
step field, so those pushes carried nothing a client could observe. Real
state transitions still emit from the scheduler's claim and completion
paths, from `submit`, and from the three `actions.rs` sites. Net effect is
strictly fewer redundant SSE pushes.

Docs: `docs/coordinator.md` still listed `step` as a `NodeView` wire field
and `docs/web-ui/dashboard.md` documented a cyan `↳ <step>` sub-line under
each queue row. Neither has existed since #2661 — both corrected here, plus
the `job_queue/model.rs` module doc.

Not touched: `frontend/packages/dashboard/src/system-sections.css` has a
dead `.rqe-step` rule with no JS referencing it. Left for the frontend
owner rather than deleted here.

Closes: #2664

docs/web-ui/dashboard.md

@@ -220,12 +220,10 @@ op for the same agent collapses into the existing entry. All timing
 labels stay live: running entries tick elapsed seconds every second;
 queued and terminal ("done N ago" / "failed N ago") labels tick every
 30s so keyed rows never show stale timestamps as they persist across
-`rebuild_queue_changed` snapshots. When the worker has annotated the
-current phase a cyan `↳ <step>` sub-line appears under the main row
-showing the in-flight step name (e.g. `↳ meta prepare_deploy` →
-`↳ nixos-container update` → `↳ finalize deploy`). Terminal
-transitions clear `step` on the backend so Done / Failed rows don't
-render stale labels.
+`rebuild_queue_changed` snapshots. The in-flight phase is the running
+**node's kind** in the node chain — there is no separate sub-step
+label (the old cyan `↳ <step>` sub-line went away with the DAG queue:
+each phase is its own node now).
 Queued entries carry a `✗` cancel button on the right edge;
 running / done / failed / cancelled entries don't show it — the
 backend refuses cancellation for non-`Queued` rows anyway
@@ -242,7 +240,7 @@ It's keyed to the running entry's `build_log_id` and opens one
 `EventSource` to `GET /api/build-logs/id/{id}/stream` (the same stream
 the BUILD L0GS tab uses; the stream replays accumulated output on
 connect). It lives in its own container outside `#rebuild-queue-section`
-so the queue's per-row re-render (rows rebuild as the `step` advances)
+so the queue's per-row re-render (rows rebuild as nodes advance)
 never tears down the open stream; it hides when nothing is building and
 each row keeps its `logs →` link out to the full build log history.
 
@@ -912,7 +910,7 @@ agent is stale. Banner pulses on each broker SSE event
 `queued` / `running` entries, 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). It replaces the
-old per-transient spinner list; the actual running step for each
+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.