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

@@ -152,6 +152,7 @@ pub(super) async fn run_node(
         NodeKind::MatrixSweep => run_matrix_sweep().await,
         NodeKind::WebhookRegister => run_webhook_register().await,
         NodeKind::KnowledgePull => run_knowledge_pull(coord).await,
+        NodeKind::WantedPull => run_wanted_pull(coord).await,
     };
     (builder, result)
 }
@@ -224,6 +225,15 @@ async fn run_knowledge_pull(coord: &Arc<Coordinator>) -> Result<()> {
     crate::workers::knowledge::pull(coord).await
 }
 
+/// Boot-time swarm wanted-state pull as a DAG node — see
+/// [`NodeKind::WantedPull`]. "The controller has declared nothing" is a
+/// successful outcome the worker logs, so an error reaching here means the
+/// read itself failed and this hive is running blind to its declaration —
+/// which is exactly the state worth seeing on the dashboard.
+async fn run_wanted_pull(coord: &Arc<Coordinator>) -> Result<()> {
+    crate::workers::wanted::pull(coord).await
+}
+
 /// Resolve the DAG's approval row the way this node's own `outcome` says.
 ///
 /// Nothing is inspected: a template emits one of these per outcome, each edged to