build an archetype agent from internal/meta only at the archetype it has now

on deploy, hive-c0re takes the internal/meta head for an archetype agent only
when the head lists that same archetype, and for a custom agent only when the
head lists it as custom, so a switch between the two, or to another archetype,
builds from the hive's own flake until the swarm commits the new flake.
the record location is described in the same docs paragraph.

docs/agent-lifecycle/config-changes.md

@@ -173,13 +173,16 @@ older or newer than the controller keeps building.
 
 - **Choosing the commit.** The rebuild's `MetaSync` node reads the repo's
   default-branch head with the hive's read token (`forge::reader_token()`)
-  and takes it when its `flake.nix` lists the agent and, for a custom agent,
-  pins the config commit at the head of `agent-configs/<n>` `main` now.
+  and takes it when its `flake.nix` builds the agent the way the agent needs now:
+  a custom agent from the config commit at the head of `agent-configs/<n>`
+  `main`, an archetype agent from the archetype it has now. An agent switched
+  between custom and archetype, or to another archetype, fails that test.
   A hive without the `core` token file that nix's git reads, a repo with no
   commit, a head that lacks the agent and a head behind the config all select
-  the hive's own flake. `MetaSync` records the commit under the agent's
-  runtime directory; `Prebuild` and `Swap` read that record, so
-  both build one flake. A first deploy resolves the commit in its `Create`
+  the hive's own flake. `MetaSync` records the commit in `hive-c0re`'s own state,
+  `/var/lib/hyperhive/meta-rev/<n>`, which the agent can't write (the container mounts its runtime
+  directory read-write); `Prebuild` and `Swap` read that
+  record, so both build one flake. A first deploy resolves the commit in its `Create`
   node, since it has no `MetaSync`.
 - **The build.** `hive-c0re` prebuilds
   `git+<forge>/internal/meta.git?rev=<commit>#nixosConfigurations.<n>…` and