docs: stop asserting DagView/NodeView after their deletion

The deletion PR removed the types but left ~10 sites still describing
them. Two are real breakage rather than staleness: rustdoc intra-doc
links to deleted items ([NodeView::kind] and [Self::snapshot] in
job_queue/mod.rs). Neither clippy --all-targets -D warnings nor cargo
test resolves intra-doc links, so the tree was green with both already
dangling.

The rest reassert facts the deletion made false: docs/coordinator.md
documented the event as RebuildQueueChanged { seq, queue: [DagView...] }
with a per-node field list, and three sites pointed at the removed
/api/state.rebuild_queue endpoint.

One is pointer rot rather than a rename, and no grep for a deleted name
finds it: SchedulesChanged justified itself as "same snapshot-shape
rationale as RebuildQueueChanged" -- which the deletion turned into the
one event that is not a snapshot. Repointed at TombstonesChanged /
MetaInputsChanged, in both the Rust doc and the dashboard doc.

Two are pre-existing and strictly out of scope, swept under the
pfadfinderregel because the same grep surfaced them: hive-sh4re/README
advertised a jobs module that crate has not had since the host-sock
split, and hive-host-sock/README claimed its own payload types live in
hive-sh4re.

Docs and comments only -- no behaviour, no API, no test changes.

docs/approvals.md

@@ -441,8 +441,8 @@ the config PR, and for a spawn runs the post-spawn forge bookkeeping.
 Two visible consequences:
 
 - **Operator dashboard**: after clicking APPR0VE the work-in-progress
-  shows up on the *rebuild queue* card (`/api/state.rebuild_queue`
-  + live `rebuild_queue_changed` events), not on the approvals panel
+  shows up on the *rebuild queue* card (`GET /api/jobq/graph`, refetched
+  on every `rebuild_queue_changed` tick), not on the approvals panel
   (which already moved the row to "approved"). A long meta-update
   cascade renders as a parent DAG with one child rebuild per affected
   agent — see `docs/web-ui.md` for the layout.