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/coordinator.md

@@ -20,7 +20,7 @@ fast-lane follow-up, the meta-update cascade pre-enqueue — are all just DAG
 
 The **DAG** is the unit of cancel / approval-resolution and the
 dashboard group; the **node** is the unit of scheduling / execution /
-build-log / step label. Deps are intra-DAG edges only (`AfterOk` by default:
+build-log. Deps are intra-DAG edges only (`AfterOk` by default:
 the dep must succeed, a failed/cancelled dep cancels the dependent —
 cancel-downstream). Cross-DAG ordering comes from the per-agent lease,
 never from edges between DAGs. Submit-time validation (petgraph `toposort`)
@@ -167,7 +167,7 @@ without a row are seeded from observed state on first touch (running ⇒
 
 The admin-socket responses carry the submitted DAG ids; `hivectl` polls
 `HostRequest::QueueDag` (~1s) and prints a progress line per DAG — roll-up
-glyph, template, agent, node chain with the running node's step label — so
+glyph, template, agent, node chain — so
 CLI verbs block until their jobs finish (`--no-wait` opts out; failures exit
 non-zero). Nodes appended in-DAG (a `MetaLock` growing per-agent rebuild
 subgraphs, a `Reconcile` fanning its `Start`/`Stop`) join the same DAG, so
@@ -248,11 +248,12 @@ cancelled-while-queued, which fails the approval instead of dangling it).
 `DagView` carries the entry-level fields (`id`, `kind` = template string,
 roll-up `state`, `source`, `reason`, timestamps, `inputs`,
 `approval_id`) plus `nodes: [NodeView…]` — per-node `agent`, `kind`, `deps`,
-`state`, `step`, `build_log_id`, timestamps, `error`. There is **no
+`state`, `build_log_id`, timestamps, `error`. There is **no
 DAG-level `agent`** (agent is per-node, so a DAG can span agents); consumers
-derive a DAG's agent(s) from its nodes. Step labels and build logs are
-**per-node**; the dashboard renders the node chain on each queue card and
-keys the live-log panel off the running node.
+derive a DAG's agent(s) from its nodes. The node kind *is* the phase label —
+there is no separate sub-step string; build logs are **per-node**. The
+dashboard renders the node chain on each queue card and keys the live-log
+panel off the running node.
 
 ---
 

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.