hive-c0re: serialise the matrix and knowledge sweeps through the job queue

The matrix sweep and the /knowledge pull each had concurrent callers
(#4723 item 4). Two overlapping knowledge pulls fail on .git/index.lock
and the remote-tracking ref lock: 30 of 30 concurrent replays of the
reset/clean/pull sequence in a scratch repo errored, 0 of 10 sequential
ones did. Two overlapping matrix sweeps on a hive with no persisted
Space / chat-room id both miss the by-name lookup and both createRoom
(from reading the code, not reproduced against a homeserver). On every
boot the MatrixSweep DAG node and the main.rs loop's immediate first
call ran at once.

Every sweep now runs as a job node, and each sweep's node holds its own
capacity-1 queue resource (Resource::MatrixSweep,
Resource::KnowledgeTree), the MetaWindow pattern: the scheduler never
starts a second pass of one sweep while the first holds the resource,
and different sweeps still run side by side.

- templates::matrix_sweep / templates::knowledge_pull build the node
  with its resource; boot, the periodic loops and the swarm event all
  use them.
- JobQueue::insert_unless_live folds a submission into a live node of
  the same kind instead of queueing another. Periodic ticks fold into a
  queued or running pass. The swarm knowledge event folds into a queued
  pull only, and queues one behind a running pull, which may have
  fetched before the push.
- The main.rs matrix loop no longer sweeps immediately at startup; the
  boot MatrixSweep node is the startup pass, as KnowledgePull already
  was for knowledge.
- The executors bound each pass (10 min matrix, 5 min knowledge), since
  a hung pass would otherwise hold its resource against every later one,
  and own the sweep-health banners, so every pass reports to them.

Replaces the SweepLock version of this branch, per review.

Refs #4723

hive-c0re/src/workers/auto_update.rs

@@ -462,15 +462,17 @@ fn boot_action(wanted: Option<crate::power::Wanted>, fresh: bool, running: bool)
 /// as real work on the dashboard instead of an invisible `tokio::spawn` that
 /// only surfaces on failure. Five independent, build-slot- and lease-exempt
 /// roots — no dependency edges between them, matching the existing
-/// `Reconcile`-root pattern in [`boot_nodes`].
+/// `Reconcile`-root pattern in [`boot_nodes`]. `MatrixSweep` and
+/// `KnowledgePull` hold their sweep's own resource, so each queues behind any
+/// pass of the same sweep already running.
 fn submit_startup_sweep_nodes(coord: &Arc<Coordinator>) {
     use crate::job_queue::NodeKind;
 
     if let Err(e) = coord.job_queue.insert_job(|b| {
         let _ = b.node(NodeKind::ForgeSweep);
-        let _ = b.node(NodeKind::MatrixSweep);
+        let _ = crate::job_queue::templates::matrix_sweep(b);
         let _ = b.node(NodeKind::WebhookRegister);
-        let _ = b.node(NodeKind::KnowledgePull);
+        let _ = crate::job_queue::templates::knowledge_pull(b);
         let _ = b.node(NodeKind::WantedPull);
         Vec::new()
     }) {