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

@@ -127,10 +127,10 @@ mod tests {
                 hive_jobq::resources::ResourceTable::new(),
             ))),
             webhook_secret: None,
-            config_prs: None,
+            config_prs: std::sync::Arc::default(),
             swarm_name: None,
             auth: None,
-            forge: None,
+            forge: std::sync::Arc::default(),
             create_gate: std::sync::Arc::default(),
             accounts: Accounts::Fake(Arc::clone(store)),
         }