check-issue-refs: blanket-ban tracker tags in markdown too, no exceptions

docs/agent-lifecycle/agent-hierarchy.md

@@ -4,8 +4,8 @@ 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: #361
-(`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`).
+special-cased in the meantime. Tracking issue:
+`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/361`.
 
 ## Where the tree lives
 

docs/agent-lifecycle/approvals.md

@@ -69,7 +69,8 @@ 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 #1787) makes the agent a
+   = operator team; see "Forge mirror" and
+   `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`) 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
@@ -476,7 +477,8 @@ 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 + #1787). hive-c0re passes the tokenised push
+self-merge its PR (see the End-to-end flow +
+`$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1787`). 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 the #1762 lane). This is a no-op fallback on
+enhancement — see `$HIVE_FORGE_URL/hyperhive/hyperhive/issues/1762`). 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.