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.

docs/swarm/README.md

@@ -25,6 +25,9 @@ grafana, the controller, authelia, …) →
   kept by the swarm and fired in each agent's container. → [`schedules.md`](schedules.md)
 - **inference settings** — the model and effort the swarm sets for an agent,
   over its own. → [`inference.md`](inference.md)
+- **resource caps** — the CPU and memory cap the swarm sets for an agent,
+  over its hive's. →
+  [`coordinator.md`](../scheduler/coordinator.md#container-resource-limits)
 - **review classifier** — planned, not implemented yet: checks a PR against
   its repo's own yes/no rules and posts the result as a review. →
   [`review-classifier.md`](review-classifier.md)