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.
 
 ---