refactor(#2897): carry the approval id on the deploy nodes, not the Dag

`DagSpec`/`NodeKind::Dag` carried an `Option<i64>` approval id that four
deploy phases read back out through `Claim`, via a fallible helper whose
error ("approval deploy dag N has no approval_id") described a state the
type system should have forbidden. Two other templates (`spawn`,
`meta_update`) set the field for nothing: their approval is resolved by
the `ResolveApproval` tails, which already carry the id themselves.

So the id moves onto the nodes that actually need it —
`DeployWindow` / `MergeVerify` / `DeployApply` / `FinalizeDeploy` /
`DeployTail` each take an `i64`, the same way `ResolveApproval` always
has. `templates::approval_deploy` builds all of them in one place with
the value in hand, and `deploy_rebuild_nodes` takes it as a parameter so
the `FinalizeDeploy` it appends at runtime is constructed the same way.

Falls out of that:
- `deploy_approval_id` and its runtime error path delete; each executor
  takes the id from its own node payload at dispatch.
- `run_deploy_window` had nothing left to do but validate that id, so the
  node joins `Dag` on the shared no-op arm.
- `Claim::approval_id` and `DagMeta::approval_id` delete.
- `dag_view`'s DAG-level projection onto `DeployWindow` reads the payload
  instead. The wire `NodeView::approval_id` is unchanged: still set on
  the deploy root alone, so the dashboard still renders one approval link
  per DAG rather than one per phase.

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

hive-c0re/src/job_queue/submit.rs

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