docs/integrations, hive-c0re nix: the agent config input is the local applied mirror

forge.md said the meta flake fetches agent-configs over git+http through a
credential helper. The input is git+file://<applied> (meta.rs), and
hive-c0re's own git reads use forge::reader_token(). Fix the same claim in
the comments above the hive-c0re gitconfig and the credential helper. No
code change.

docs/integrations/forge.md

@@ -117,11 +117,13 @@ Two things live in the `agent-configs` Forgejo organization:
   hive-c0re pushes nothing to this org; it only reads from it.
   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 [config-changes.md § Meta flake](../agent-lifecycle/config-changes.md#meta-flake)), 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 agent's **persistent meta flake input** is the hive's local `applied`
+  mirror of this repo (`agent-<n>.url = git+file://<applied>`; see
+  [config-changes.md § Meta flake](../agent-lifecycle/config-changes.md#meta-flake)),
+  so building never depends on the forge being reachable. hive-c0re's own git
+  reads of this repo, which fill the mirror, authenticate with the hive's read
+  token through `forge::reader_token()` (see
+  [How a hive reads the forge](#how-a-hive-reads-the-forge)).
 - The dashboard links each container's deployed config commit to this
   config repo on the swarm's forge (`swarm.forge.publicUrl`; `null` means no
   link), so operators can go straight from the SW4RM tab into