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/agent-lifecycle/persistence.md

@@ -411,6 +411,13 @@ Contents:
   default for CPU. The `CPUWeight=` / `IOWeight=` shares in the same
   drop-in have **no** per-agent override — they're hive-wide only and
   come straight off `HiveEnv`, so this file has no field for them.
+- `swarm-resource-limits.json` — the caps the swarm sets for this
+  hive's agents, same shape as `resource-limits.json`. Written only by
+  `workers::swarm_limits`, which copies each agent's key of the swarm's
+  `agent-limits` bucket here every 30 seconds. A field set here replaces
+  that field's answer from `resource-limits.json` and the hive-wide
+  default. Every value passes the same validators as the operator's
+  overrides first, and one bad value makes the worker change nothing here.
 
 The root agent has the meta dir RO-mounted at `/meta/`.