deploy the closure the swarm declares, read no forge head, drop the update badge

docs/integrations/forge.md

@@ -63,7 +63,6 @@ store certificate, every time it reads the forge. A hive whose store holds
 none reads nothing. These reads go through it, and none of them needs a local
 forge container:
 
-- resolving the config commit `internal/meta` pins for a build
 - cloning and pulling `/knowledge`
 
 The hive builds nothing, so no nix process reads the forge as the hive's
@@ -107,19 +106,12 @@ Two things live in the `agent-configs` Forgejo organization:
   `main` directly nor self-merge. An operator's merge in the Forgejo UI
   deploys the merged commit (see
   [config-changes.md § Config changes](../agent-lifecycle/config-changes.md#config-changes)).
-  hive-c0re pushes nothing to this org; it only reads from it.
+  hive-c0re pushes nothing to this org and reads nothing from it.
   Repos stay private, so an agent can't read another
   agent's config. The agent's **persistent meta flake input** is this repo's `main` head,
   pinned by sha in `internal/meta` (`agent-<n>.url =
 git+<forge>/agent-configs/<n>.git?rev=<sha>`; see
   [config-changes.md § Meta flake](../agent-lifecycle/config-changes.md#meta-flake)).
-  hive-c0re's own git reads of this repo, which resolve the sha, 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 4G3NTS tab into
-  the rendered repo without an extra `git` step.
 
 The `hive-forge` CLI (separate workspace crate, see
 [`README.md`](../README.md) file map) wraps the Forgejo REST API