hand agents the dashboard port, pinned claude and otel labels at container start

The three values that differ per host (deploy.hive-controller.dashboardPort,
claudeCodePackage and otel.extraResourceAttributes) no longer go into the
meta flake. hive-priv writes them into the container's
/etc/hyperhive-hive-facts with the hive name and domain, and the agent
reads them at boot:

- HIVE_DASHBOARD_PORT reaches every unit through the hive-facts generator;
  the web UI still defaults to 7000 without it.
- `claude` on PATH is a wrapper that runs HYPERHIVE_CLAUDE_CODE_PATH's
  claude when it is there, and the container's own claude-code otherwise.
  The host's serve.json keeps gc-rooting the pinned build.
- OTEL_RESOURCE_ATTRIBUTES moves out of the units' Environment= into a
  boot-time generator, which appends HYPERHIVE_OTEL_EXTRA_RESOURCE_ATTRIBUTES.

The agent options services.hyperhive.agent.claudeCodePath (now a removed
option) and otel.extraResourceAttributes go; only the meta render set them.
render_flake takes no HiveEnv any more, so the memory-cap render test and
render_hive_flake_at, which only existed to vary HiveEnv into the render,
go with it.

Refs #4857

docs/process/conventions.md

@@ -39,11 +39,15 @@ Four env vars cover the identity surface, read by
   name.
 
 Inside an agent container, the hive's name and domain don't come from the
-agent's build. `hive-priv` writes them to `/etc/hyperhive-hive-facts` before
-every container start. The agent's environment generator
-(`nix/agent-modules/hive-facts.nix`) passes them to every unit, including
-`hivectl choom` sessions, and `/etc/set-environment` exports them in login
-shells that no unit starts (`nixos-container root-login`). Neither is part of
+agent's build, and neither do the hive's other per-host values: the dashboard
+port (`HIVE_DASHBOARD_PORT`), the pinned claude-code
+(`HYPERHIVE_CLAUDE_CODE_PATH`) and extra OTEL labels
+(`HYPERHIVE_OTEL_EXTRA_RESOURCE_ATTRIBUTES`). `hive-priv` writes them to
+`/etc/hyperhive-hive-facts` before every container start, leaving out any the
+hive doesn't set; the agent then uses its own default. The agent's environment
+generator (`nix/agent-modules/hive-facts.nix`) passes them to every unit,
+including `hivectl choom` sessions, and `/etc/set-environment` exports them in login
+shells that no unit starts (`nixos-container root-login`). None is part of
 an agent's closure, and an agent started on another hive reports that hive.
 
 `hive_name` + `swarm_name` are **distinct** from

docs/process/gotchas.md

@@ -145,9 +145,9 @@ and every agent runs that build.
 
 What crosses is the **store path**, not the derivation. Containers
 share the host's `/nix/store`, so the binary is already reachable
-inside them with its whole closure; hive-c0re writes the path into each
-agent's flake as a string literal and the agent module symlinks
-`bin/claude` onto PATH. Two things rule out the natural-seeming alternatives: a
+inside them with its whole closure. `hive-priv` writes the path into each
+container's `/etc/hyperhive-hive-facts` at start, and the agent's `claude`
+wrapper on PATH runs its `bin/claude`. Two things rule out the natural-seeming alternatives: a
 `path:/nix/store/<pkg>` flake input is re-copied into the store as a
 reference-less `-source` (so the runtime closure never arrives), and
 `lib.types.package` fed a bare path runs `builtins.storePath`, which
@@ -171,7 +171,7 @@ expected.
 
 <!-- vale write-good.Passive = NO -->
 
-The catch is that a path written into a generated flake is text, not a
+The catch is that a path handed to the container at start is text, not a
 reference — the container's closure doesn't keep the binary alive.
 The **host** does: it interpolates the package into
 `/etc/hyperhive/serve.json`, so it lands in the host's system closure
@@ -180,7 +180,7 @@ string context, which is the load-bearing detail; discard the context
 anywhere on that path and `nix-collect-garbage` will eventually take
 the hive's `claude` out from under it. The price of the root is that
 `nix-collect-garbage` can't reclaim an old `claude-code` until every
-agent has rebuilt past it and the old generations are gone.
+agent has restarted past it and the old generations are gone.
 
 <!-- vale write-good.Passive = YES -->