feat(#3124): converge the hive onto the agent set the swarm declares

The deploy event is a nudge with no second path: core NATS is
at-most-once, so a hive that was down when the controller published
simply never learns that an agent is meant to exist here. This adds the
repair path — one boot-time DAG node that reads this hive's own key in
the `hive-wanted` bucket and converges the agents it names.

Two semantics settled on the issue thread, and both are places where a
plausible implementation is the wrong one:

- **Absence is not a deletion order.** No bucket, no key, or an agent
  the value does not name all mean the controller has said nothing.
  Swarm-side lifecycle does not yet cover agents that predate it, so
  "converge to exactly this set" would tear down every agent the swarm
  has not adopted. `plan` only ever inspects the agents a declaration
  names.
- **An unrecognised state is inert.** `AgentState` is an open enum: a
  value this build cannot read deserialises into `Unrecognised` and is
  left alone. A closed enum would force "not `Up`" onto a state like
  `paused`, so a controller that learned a new value would take agents
  down on every hive not yet updated.

Divergence is measured against the hive's **stored power intent**, not
the container's observed running state — an agent that is down while its
intent says `Up` is already the boot reconcile's work, and a loop reading
`is_running` would insert a start DAG behind that reconcile's back on
every boot. A hive that already agrees with its declaration queues
nothing at all.

`queue_first_deploy` is extracted from the deploy-event path rather than
open-coded here, for the power-intent seed: without it `first_deploy`'s
tail `Reconcile` seeds `Wanted` from a container that exists but has not
started yet, which locks the agent to `Offline` on its first reconcile.

The read is authorised as-is: `store.get` takes async-nats' direct-get
arm (the KV bucket is created with `allow_direct`), which is exactly the
`$JS.API.DIRECT.GET.KV_hive-wanted.$KV.hive-wanted.<hive>` subject
`swarm-nats-auth` grants a hive. The fallback subject is not granted, and
a refused NATS request surfaces as a timeout rather than an error.

Nothing writes the bucket yet — the controller-side writer is the other
half of #3124, so this does not close it.

hive-c0re/src/job_queue/model.rs

@@ -345,6 +345,14 @@ pub enum NodeKind {
     /// [`NodeKind::MatrixSweep`]: the periodic hourly re-pull stays a
     /// background loop, only the boot-time instance is a DAG node.
     KnowledgePull,
+    /// One-shot boot-time pull of the agent set the swarm controller declares
+    /// for this hive (`wanted::pull`), converging the agents it names.
+    ///
+    /// Unlike the three above there is **no** background loop behind this one:
+    /// boot is the whole cadence. The per-agent fast path is the deploy event
+    /// (`swarm_status`), and this is what repairs a missed one. Agentless — it
+    /// reads the whole declaration, not one agent.
+    WantedPull,
 }
 
 /// How a hive-c0re node describes itself to a generic graph viewer.
@@ -424,6 +432,7 @@ impl NodeKind {
             NodeKind::MatrixSweep => "matrix_sweep",
             NodeKind::WebhookRegister => "webhook_register",
             NodeKind::KnowledgePull => "knowledge_pull",
+            NodeKind::WantedPull => "wanted_pull",
         }
     }
 
@@ -467,7 +476,8 @@ impl NodeKind {
             | NodeKind::ForgeSweep
             | NodeKind::MatrixSweep
             | NodeKind::WebhookRegister
-            | NodeKind::KnowledgePull => "",
+            | NodeKind::KnowledgePull
+            | NodeKind::WantedPull => "",
         }
     }