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

nix/host-modules/swarm-controller.nix

@@ -191,7 +191,7 @@ let
 
   # Unconditional: every swarm has a forge, reached by name wherever it runs.
   # The token is not here: the daemon reads it from the swarm's secret store at
-  # start (`forge.rs`), and runs without forge access when it cannot.
+  # start (`forge.rs`), and re-reads it in the background until it is there.
   forgeEnv = {
     SWARM_CONTROLLER_FORGE_URL = "https://${forgeCfg.domain}";
     # `agent-configs` org avatar for the forge-objects pass