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/model.rs

@@ -154,13 +154,17 @@ pub enum NodeKind {
     /// Cheap, too: the window has to span the container build regardless (see
     /// [`NodeKind::DeployApply`]), so nothing is over-serialised by hoisting
     /// the slot and the lease up alongside it.
-    DeployWindow { agent: String },
+    ///
+    /// Carries the approval row every phase below it re-reads, like each of
+    /// those phases does — the id is the node's own payload, not something a
+    /// DAG-level catch-all hands down.
+    DeployWindow { agent: String, approval_id: i64 },
     /// Deploy phase 1 — **verify only, mutates nothing.** Drift-gate the
     /// approval's PR head, fetch it into the applied repo, and eval-verify the
     /// merge head. Any failure here aborts the deploy with the forge state
     /// untouched, so it is safely retryable and cancel-safe: nothing downstream
     /// has happened yet.
-    MergeVerify { agent: String },
+    MergeVerify { agent: String, approval_id: i64 },
     /// Deploy phase 2 — the irreversible fast-forward plus the *opening* half of
     /// the two-phase meta deploy: park the rollback ref, ff-merge the reviewed
     /// head to `main` via the forge API, ff `applied/main`, and
@@ -174,7 +178,7 @@ pub enum NodeKind {
     /// staged-lock window is likewise its own node
     /// ([`NodeKind::FinalizeDeploy`]), and the compensation path is
     /// [`NodeKind::DeployTail`].
-    DeployApply { agent: String },
+    DeployApply { agent: String, approval_id: i64 },
     /// Deploy phase 3 — close the two-phase meta deploy once the rebuild
     /// subgraph under [`NodeKind::DeployApply`] has come up clean: drop the
     /// rollback ref, plant the `deployed/<id>` tag, commit the staged
@@ -190,7 +194,7 @@ pub enum NodeKind {
     /// The trailing `meta::finalize_deploy` stays warn-only: by then the
     /// container already runs the new config, and an uncommitted staged lock is
     /// something the operator can commit by hand.
-    FinalizeDeploy { agent: String },
+    FinalizeDeploy { agent: String, approval_id: i64 },
     /// Deploy compensation **and bookkeeping** tail — `AfterAny`
     /// [`NodeKind::DeployApply`], so it runs on success, failure, and cancel
     /// alike, in the same spirit as the rebuild template's tail `Reconcile`
@@ -215,7 +219,7 @@ pub enum NodeKind {
     /// this node a no-op. Parking it in git rather than in a node payload also
     /// means it survives a `hive-c0re` restart mid-deploy, which an in-memory
     /// queue does not.
-    DeployTail { agent: String },
+    DeployTail { agent: String, approval_id: i64 },
     /// Tail node of an approval-carrying DAG (spawn / opaque deploy / config-PR
     /// merge): resolve the approval row from how the work actually ended.
     ///
@@ -277,7 +281,6 @@ pub enum NodeKind {
         source: Source,
         reason: String,
         transient: Option<TransientKind>,
-        approval_id: Option<i64>,
         inputs: Vec<String>,
         created_at: i64,
     },
@@ -336,11 +339,11 @@ impl NodeKind {
             | NodeKind::Drain { agent }
             | NodeKind::WriteDropin { agent }
             | NodeKind::WritePermFile { agent, .. }
-            | NodeKind::DeployWindow { agent }
-            | NodeKind::MergeVerify { agent }
-            | NodeKind::DeployApply { agent }
-            | NodeKind::FinalizeDeploy { agent }
-            | NodeKind::DeployTail { agent }
+            | NodeKind::DeployWindow { agent, .. }
+            | NodeKind::MergeVerify { agent, .. }
+            | NodeKind::DeployApply { agent, .. }
+            | NodeKind::FinalizeDeploy { agent, .. }
+            | NodeKind::DeployTail { agent, .. }
             | NodeKind::EmitRebuilt { agent, .. }
             | NodeKind::SetWanted { agent, .. } => agent,
             NodeKind::MetaLock { .. }
@@ -456,13 +459,6 @@ pub struct DagSpec {
     pub source: Source,
     /// Free-form "why".
     pub reason: String,
-    /// The approval row this DAG belongs to, for display + the `approval_id` on
-    /// every [`Claim`]. The *resolving* of it rides the
-    /// [`NodeKind::ResolveApproval`] tail node instead — this field does not
-    /// drive it.
-    ///
-    /// [`Claim`]: super::Claim
-    pub approval_id: Option<i64>,
     /// Meta-update only: the inputs to bump. Display copy lives on the DAG.
     pub inputs: Vec<String>,
     /// Dashboard transient pill (and crash-watch suppression) held for