agents: read the memory cap at boot, not from the build

An agent's memory cap was rendered into its flake (`memoryMaxBytes` →
`services.hyperhive.agent.claudeMemoryMaxBytes`), so the closure depended
on it and a changed cap reached the JSC heap ceiling and the subagent
`MemoryHigh=` only after a rebuild.

hive-c0re now writes the effective `MemoryMax=` in bytes to the agent's
runtime dir (`/run/hive/memory-max-bytes` inside) in `write_dropins`,
from the same value the drop-in gets. The file is removed for
`infinity` or a RAM percentage, and left alone when the drop-in is kept.

Inside the container, `nix/agent-modules/memory-cap.nix` reads it at
boot: an environment generator sets `BUN_JSC_forceRAMSize` (75%) for
every unit and `machinectl shell`, `/etc/set-environment` exports it in
login shells, and a unit generator writes `MemoryHigh=` (2/3) as a
drop-in for `hive-subagent-daemon`.

The render drops `memoryMaxBytes`, the agent option is removed (both
spellings fail eval with a removal message), and
`effective_memory_bytes_from` goes with its only caller.

Part of #5081 (slice S0-2).

hive-c0re/src/server.rs

@@ -433,10 +433,9 @@ async fn handle_set_resource_limits(
         &hive.agent_memory_max,
     )?;
     Ok(HostResponse::messages(vec![format!(
-        "{name}: CPUQuota={cpu} MemoryMax={mem} — the cgroup cap itself is live now (restart \
-         the container if it's running and needs the new cap immediately), but the derived \
-         Claude/JSC heap ceiling is baked in at build time, so it needs a REBUILD \
-         (`hivectl agent {name} rebuild`) to actually track this change"
+        "{name}: CPUQuota={cpu} MemoryMax={mem} — the cgroup cap itself is live now; the \
+         Claude/JSC heap ceiling and the subagent MemoryHigh= derived from it follow at the \
+         container's next start (restart it if it's running and needs them now)"
     )]))
 }