check-issue-refs: catch full forge issue URLs too, drop internal links from docs entirely

docs/agent-lifecycle/agent-hierarchy.md

@@ -4,8 +4,7 @@ Every agent has a place in an operator-editable parent/child tree, used
 to scope which agents can manage which others. This doc covers how
 hive-c0re stores and edits the tree today, the rules that are meant to run on top
 of it once enforcement is finished, and where the manager still gets
-special-cased in the meantime. Tracking issue:
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`.
+special-cased in the meantime, as a tracked cleanup.
 
 ## Where the tree lives
 
@@ -235,10 +234,7 @@ uid 0 and have the setuid bit set."
 
 ## Cross-references
 
-- Milestone: "Agent privileges and sub-agents"
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`)
-- Dashboard render: "show agent topology in container list"
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/363`)
-- Audit table source: milestone comment
-  (`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361#issuecomment-3335`)
+- Milestone: "Agent privileges and sub-agents" (tracked internally)
+- Dashboard render: "show agent topology in container list" (tracked internally)
+- Audit table source: milestone comment (tracked internally)
 - Operator/agent trust boundary (orthogonal axis): [`boundary.md`](../trust-boundary/boundary.md)

docs/agent-lifecycle/approvals.md

@@ -69,8 +69,7 @@ request.
    and no approval. (it's currently mounted read-write, which is a
    defect tracked separately, not an authoring path.)
    Branch protection (push/merge allowlist = `core`, approvals allowlist
-   = operator team; see "Forge mirror" and
-   `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`) makes the agent a
+   = operator team; see "Forge mirror" below) makes the agent a
    write collaborator that **can't merge its own config PR**.
 2. hive-c0re's `/webhook/config-pr` endpoint receives the Forgejo
    `pull_request` event (opened / synchronized / reopened) and queues a
@@ -477,8 +476,7 @@ repo — so it can push a branch and open a config PR — but not a member
 of any other agent's, so it can't reach another agent's config through
 the forge. Branch protection keeps `main` push/merge `core`-only with
 operator-team approval, so an agent can't fast-forward its own config or
-self-merge its PR (see the End-to-end flow +
-`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`). hive-c0re passes the tokenised push
+self-merge its PR (see the End-to-end flow above). hive-c0re passes the tokenised push
 URL inline to `git push`, never writing it into
 `applied/<n>/.git/config`; that repo is RO-bind-mounted into the root
 agent, and a stored token would leak core's admin credential to an

docs/agent-lifecycle/persistence.md

@@ -437,7 +437,7 @@ would only be transient.
 
 On a btrfs host, `lifecycle::ensure_agent_state_subvolume` creates a brand-new agent's state root as a
 **btrfs subvolume** instead of a plain directory (progressive
-enhancement — see `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1762`). This is a no-op fallback on
+enhancement). This is a no-op fallback on
 non-btrfs hosts and for any agent whose root already exists, so
 nothing is automigrated: existing agents keep their plain dirs
 until an explicit opt-in upgrade.