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

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