docs(#2502): meta flake input is the forge config repo, deploy overrides to local applied

docs/approvals.md

@@ -213,13 +213,31 @@ transient.
 
 The hive-c0re-owned repo at `/var/lib/hyperhive/meta/`
 declares one flake input per agent (`agent-<n>.url =
-"git+file:///var/lib/hyperhive/applied/<n>"`) and one
+"git+http://<forge>/agent-configs/<n>.git"`) and one
 `nixosConfigurations.<n>` output per agent. Each output wraps
 `inputs.agent-<n>.nixosModules.default` with the identity +
 `HIVE_PORT` / `HIVE_LABEL` / `HIVE_DASHBOARD_PORT` injection
 module that `setup_applied` used to generate inline.
 Containers run against `--flake /var/lib/hyperhive/meta#<n>`.
 
+The declared input url is the agent's **forge config repo** (the
+same `agent-configs/<n>` the config-PR flow lands approved changes
+on), so the meta flake references a reviewable, reproducible source
+rather than a local checkout. hive-c0re authenticates that
+`git+http` fetch via a git credential helper that reads the live
+forge-core token — no token in the url or the lock. The deploy and
+manual-rebuild paths, however, do **not** re-lock from the forge:
+they `--override-input agent-<n>
+git+file:///var/lib/hyperhive/applied/<n>`, locking the exact config
+that `verify_commit` gated and `applied/<n>/main` was
+fast-forwarded to. That keeps a deploy/rebuild reproducible and
+independent of forge reachability — rebuilds fire on crash-restart
+and meta bumps, not just config PRs — while the declared url stays
+the forge. `sync_agents` re-renders + re-locks the persistent input;
+a plain `nix flake lock` leaves an existing applied override in
+place (it only re-locks when the declared url itself changes), so
+the forge-declared / applied-deployed split is stable.
+
 Per-deploy lock flow (two-phase, owned by
 `actions::run_merge_config_pr` → `deploy_applied_target` →
 `meta::{prepare,finalize,abort}_deploy`):

docs/forge.md

@@ -64,6 +64,11 @@ Two things live in the `agent-configs` Forgejo organization:
   approved history, the `failed/<id>` tag records the divergence).
   Repos stay private, so an agent can't read another
   agent's config. (Agents remain read-only collaborators on `core/meta`.)
+  hive-c0re also references this repo as the agent's **persistent meta
+  flake input** (`agent-<n>.url = git+http://<forge>/agent-configs/<n>.git`;
+  see [approvals.md § Meta flake](approvals.md)), fetching it as the `core`
+  user via a git credential helper that reads the live forge-core token —
+  so the config lives on the forge, not a hand-synced local checkout.
 - The dashboard links each container's "config" anchor to this
   config repo, so operators can click straight from the SW4RM tab into
   the rendered repo without an extra `git` step.