docs: repoint agent-tier option paths to services.hyperhive.agent.*

Refs #4479

docs/agent-lifecycle/agent-hierarchy.md

@@ -194,7 +194,7 @@ direct mentions, reviews, and assignments.
   session dir.
 - `HIVE_STATIC_DIR = <mergedDist>` — `tower_http::ServeDir` root for
   the per-agent web UI; merged dist = agent default + every
-  `hyperhive.frontend.extraFiles` overlay.
+  `services.hyperhive.agent.frontend.extraFiles` overlay.
 - `HIVE_ASSETS_DIR = pkgs.hyperhive-assets/share/hyperhive` — set
   directly on the unit, **not** via `environment.variables`, because
   the latter only populates `/etc/profile` which systemd services
@@ -213,7 +213,7 @@ wrappers — notably `sudo` — resolve before bare nix-store binaries; see
 general. It's load-bearing here because the harness runs as the
 per-agent user: without the wrapper dir on `PATH`, `sudo` resolves to
 the non-setuid nix-store binary and every
-`hyperhive.user.passwordlessSudo` grant fails with "must be owned by
+`services.hyperhive.agent.user.passwordlessSudo` grant fails with "must be owned by
 uid 0 and have the setuid bit set."
 
 ### `serviceConfig` highlights
@@ -229,7 +229,7 @@ uid 0 and have the setuid bit set."
   the host bind-mounts in root-owned and which holds hive-c0re's
   `mcp.sock`.
 - `User = Group = userName` — drops root inside the container; sudo is
-  the explicit escalation surface (`hyperhive.user.passwordlessSudo`).
+  the explicit escalation surface (`services.hyperhive.agent.user.passwordlessSudo`).
 
 ## Cross-references
 

docs/agent-lifecycle/persistence.md

@@ -505,7 +505,7 @@ reinstall.
 ## First-boot agent-user migration
 
 The harness runs as a per-agent unix user inside the container
-(`hyperhive.user.name`, defaults to the agent's logical label so each
+(`services.hyperhive.agent.user.name`, defaults to the agent's logical label so each
 container has a uniquely named user). Operators with legacy root-owned
 state dirs need a one-time data shuffle so they don't lose their claude
 session.
@@ -544,10 +544,10 @@ the body + marker check at that point.
 
 `hive-matrix-daemon` is a long-running matrix-sdk Client + sync
 process per agent. Serves its MCP tools directly over
-streamable-http (`hyperhive.mcp.matrixHttpPort`, no stdio bridge —
+streamable-http (`services.hyperhive.agent.mcp.matrixHttpPort`, no stdio bridge —
 same shape as `hive-bash-daemon`), emits hyperhive wake signals
 on incoming room events via `/run/hive/mcp.sock`. Conditional on
-`hyperhive.matrix.enable` (which both the daemon AND the
+`services.hyperhive.agent.matrix.enable` (which both the daemon AND the
 autoinjected `extraMcpServers.matrix` entry read).
 
 **First-boot ordering**: hive-c0re provisions the matrix token AFTER
@@ -565,7 +565,7 @@ avatar (see below).
 
 ### matrix avatar (set by the daemon over the live Client)
 
-`hive-matrix-daemon` itself publishes the agent icon (`hyperhive.icon`, an SVG) as each matrix
+`hive-matrix-daemon` itself publishes the agent icon (`services.hyperhive.agent.icon`, an SVG) as each matrix
 account's profile avatar
 (`hive-matrix-mcp::client::sync_avatar`), not a separate oneshot. After
 the daemon builds + restores an account's `Client` (authenticated,
@@ -578,7 +578,7 @@ bring-up loop, so it sets the avatar for **every** account.
 
 Nix rasterizes the SVG to a 512x512 PNG at build time (`iconPng`, via
 librsvg) and forwards its store path as `HIVE_ICON_PNG` on the daemon
-unit, gated on `hyperhive.icon != null`. No icon configured → the env is
+unit, gated on `services.hyperhive.agent.icon != null`. No icon configured → the env is
 unset → `sync_avatar` returns early and no avatar is set.
 
 Idempotency is **per-account**: an `avatar-icon-hash` file in each