swarm-controller gains forge access when the token arrives, without a restart

A controller that started before the forge's host had published its token
ran without forge access until someone restarted it: on a split-host first
deploy that is a manual step. Now the forge client lives in a slot that is
filled once (`Late<T>`, an `Arc<OnceLock<T>>`):

- `forge::enable` tries the store once at start. On failure it logs once and
  re-reads in the background with backoff (30s doubling to a 5-minute cap,
  no log per retry), fills the slot and logs once when the token is there.
- The forge passes (#5014's per-hive token mint among them), the config-PR
  poll and the webhook registration start from that moment, through
  `start_forge`'s callback.
- Job nodes and HTTP handlers read the slot when they run, so they answer
  "no forge" before and work after.

A token replaced in the store after the slot is filled still reaches the
controller with its next restart. The round-1 change that shared
`queue_identity::fetch_with_retry` is reverted; nothing else uses it.

Refs #4998

swarm-controller/src/webhook.rs

@@ -364,7 +364,7 @@ pub(super) async fn post_webhook_forge(
     match kind {
         DeliveryKind::Knowledge => announce_knowledge_change(&state).await,
         DeliveryKind::ConfigPr => {
-            if let Some(cache) = state.config_prs.as_ref() {
+            if let Some(cache) = state.config_prs.get() {
                 cache.apply_webhook_delivery(&body);
             }
             if let Some(merged) = crate::config_pr::merged(&body) {