hive-c0re: read each agent's swarm caps from agent-limits

Every 30 seconds `workers::swarm_limits` reads the `agent-limits` key of
each agent this hive has and stores the result in
swarm-resource-limits.json, where the drop-in, the heap ceiling and the
dashboard read it. A cap therefore follows its agent to whichever hive
runs it.

Each value goes through the hive's own validate_cpu_quota /
validate_memory_max before it is stored, since hive-priv renders it
verbatim into the container's drop-in, and one bad value refuses the whole
set (argus on #4268, carried over from the wanted-state consumer this
replaces). A failed read, or a bucket that does not answer, leaves the
stored caps as they are; three failures in a row raise a banner.

swarm-nats-auth grants every hive `$JS.API.DIRECT.GET.KV_agent-limits.>`:
read-only, and every agent's key, not just the hive's own. Scoping it to
the hive's agents would need a roster in the auth responder, which
policy.rs argues against. mara chose this on #4268 (c95293); narrowing it
is a possible low-priority follow-up, not planned. A test pins that the
grant reads every key, writes none, and reaches no other bucket.

Contributes to #3865.

hive-c0re/Cargo.toml

@@ -53,7 +53,11 @@ strum.workspace = true
 # Offering this hive's status to the swarm (`swarm_status`). The same crate
 # the swarm controller reads it with, and `kv` for the same reason: the
 # bucket's name and creation config belong to neither end of it alone.
-swarm-queue-client = { workspace = true, features = ["kv", "notices"] }
+swarm-queue-client = { workspace = true, features = [
+  "kv",
+  "notices",
+  "agent-limits",
+] }
 swarm-secret-client.workspace = true
 tokio.workspace = true
 tokio-stream.workspace = true