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

@@ -233,7 +233,8 @@ pub enum DashboardEvent {
     /// Full snapshot of all scheduled prompts. Emitted after every
     /// operator mutation (new / edit / cancel / fire-now) and after the
     /// worker fires or rearms a row. Same snapshot-shape rationale as
-    /// `RebuildQueueChanged` — the list is small and the client's
+    /// `TombstonesChanged` / `MetaInputsChanged` — the list is small and the
+    /// client's
     /// per-target `last_result` / `last_fired_at_unix` fields are most
     /// naturally re-derived from the full list.
     SchedulesChanged {