refactor(#2897): carry the meta-update inputs on the MetaLock node

Second of the `Dag` field removals, and the same shape as the first:
`DagSpec`/`NodeKind::Dag` carried an `inputs: Vec<String>` that exactly
one node ever read. Both reads live inside `run_meta_lock` — the
`meta::lock_update` call and the `meta_update_cascade_agents` fan-out —
so the list now rides `NodeKind::MetaLock` itself.

The executor stops touching `Claim` for this node entirely: its dispatch
arm already destructured `MetaLock { sweep, fanout }`, so `inputs` joins
them and the `claim` parameter, which had no other use, is gone.

Falls out of that:
- `Claim::inputs` and `DagMeta::inputs` delete.
- `dag_view`'s DAG-level projection onto the `MetaLock` node reads the
  payload instead. The wire `NodeView::inputs` is unchanged: still
  populated on the `meta_lock` node alone.
- the boot sweep names no inputs (it bumps `hyperhive` alone via
  `lock_update_hyperhive`), which the construction site now says out loud
  rather than leaving implicit in an empty DAG-level field.

Checked with clippy (`--all-targets -D warnings`), `cargo test -p
hive-c0re` (320 passed) and `nix fmt`. No option surface is touched, so
no nix-eval gate.

hive-c0re/src/job_queue/submit.rs

@@ -207,7 +207,6 @@ fn power_dag(
     DagSpec {
         source,
         reason,
-        inputs: Vec::new(),
         transient: Some(transient),
         nodes,
     }