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.

hive-c0re/src/dashboard/build_logs.rs

@@ -136,7 +136,7 @@ pub(super) async fn get_build_log_full(
 ///
 /// Same `BuildLogFull` JSON (`stdout` / `stderr` + header) as
 /// `get_build_log_full`; HTTP 404 when the node has no linked log (the
-/// client gates the request on `NodeView.build_log_id`, but a vacuum
+/// client gates the request on the wire node's `build_log_id`, but a vacuum
 /// race can still 404). This is the on-demand live-log-panel fetch,
 /// distinct from the `build_log_id` on the wire — that id is for
 /// deep-linking to the BUILD L0GS tab's full history view, not for