docs(pipeline-crew): drop unsupported {#id} anchors from EXPLANATION.md, repoint HOW-TO links to GitHub auto-slugs (#3613) (#3617)

GitHub's markdown renderer does not honor Kramdown `{#id}` custom-anchor
syntax — it drops the token and auto-generates a heading slug from the
heading text — so every in-repo deep link of the form `EXPLANATION.md#<id>`
resolved the file but jumped nowhere (silent dead fragment).

Drop the four `{#id}` tokens from EXPLANATION.md and repoint the four
sibling links in HOW-TO.md to GitHub's real auto-generated heading slugs
(computed with github-slugger, the algorithm GitHub uses). No `{#id}`
custom-anchor syntax remains in the pipeline-crew doc set. Doc navigation
only; no code path affected.

Fixes #3613

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Author: usirin

claude-plugins/pipeline-crew/EXPLANATION.md

@@ -16,7 +16,7 @@ grounded here against their defs: the
 [engineering-manager](agents/crew-engineering-manager.md), and the
 [chief-of-staff](agents/crew-chief-of-staff.md).
 
-## The roster law — singleton bridges vs a fungible engine {#roster-law}
+## The roster law — singleton bridges vs a fungible engine
 
 The roster is not an arbitrary list of four roles; its cardinality falls out of a single
 rule. A **bridge** owns a unique seam connecting the factory to something outside it, so it
@@ -44,7 +44,7 @@ another — a planned child becomes pickable on the board and an engine pulls it
 not a relay, is the durable coordination surface, and every channel edge is only a latency
 optimization over it.
 
-## The §CP hard gate — the engine banks, a human approves, the pipeline enqueues {#cp-gate}
+## The §CP hard gate — the engine banks, a human approves, the pipeline enqueues
 
 Some PRs touch the **agent control plane (§CP)** — the surfaces that govern how the factory
 itself behaves. Those are never auto-merged: they need a control-plane human's approval at
@@ -75,7 +75,7 @@ auto-ship on green by a founder ruling (see the [README](README.md#the-crew-is-d
 The §CP flow above governs the crew's handling of §CP work it *drives*, not merges of the
 crew defs themselves.
 
-## Verify, don't relay — a claim is not evidence until you read the artifact {#verify-dont-relay}
+## Verify, don't relay — a claim is not evidence until you read the artifact
 
 The chief-of-staff's charter is the **live verifier**: every fact it hands a human is one it
 verified against ground truth, never one it relayed. This is doctrine because the failure
@@ -100,7 +100,7 @@ unreachable. The SHA-binding half — why a verdict is `@ <sha>`, one-per-gate,
 when it is not bound to the current head — is
 [ADR 0058](../../.decisions/0058-sha-bound-verdict-contract.md).
 
-## Single-owner human comms — one channel, one owner {#single-owner-comms}
+## Single-owner human comms — one channel, one owner
 
 Exactly one role reaches a human: the chief-of-staff owns the **single** human-notification
 channel, for **both** humans the crew answers to (the operator/founder and the control-plane

claude-plugins/pipeline-crew/HOW-TO.md

@@ -38,7 +38,7 @@ substrate's `spawn-role` subcommand.
    `claude …` to route around it.
 3. **Mind the cardinality rule.** Only the engine scales by `count`/`--instance`; each bridge
    is singleton, so a second one is a `RoleUniquenessError`, not shared occupancy — that is the
-   roster law ([Explanation → roster law](EXPLANATION.md#roster-law); the bridge-vs-engine
+   roster law ([Explanation → roster law](EXPLANATION.md#the-roster-law--singleton-bridges-vs-a-fungible-engine); the bridge-vs-engine
    split is catalogued in [Reference → role roster](REFERENCE.md#role-roster--bridges-and-the-engine)).
 4. **A HITL role boots idle.** The cartographer comes up waiting for you to give it a turn — it
    is handed no self-driving loop, so it never confabulates work.
@@ -117,7 +117,7 @@ A §CP PR touches the agent control plane, so it cannot auto-ship: it needs a co
 human's **approval at the PR's current head** before the pipeline enqueues it. This is the
 **approve-then-enqueue** model (ADR 0135) — the human owns the *judgment*, the pipeline owns the
 *mechanics*. The flow is split across the crew exactly as
-[Explanation → the §CP hard gate](EXPLANATION.md#cp-gate)
+[Explanation → the §CP hard gate](EXPLANATION.md#the-cp-hard-gate--the-engine-banks-a-human-approves-the-pipeline-enqueues)
 lays out; your job as operator is to move the human gate.
 
 1. **Find the banked PR.** The engine drives a §CP lane to reviewed-ready, then **banks it on
@@ -127,7 +127,7 @@ lays out; your job as operator is to move the human gate.
 2. **Get the approval at the *current* head.** The §CP gate is a control-plane team approval
    bound to the exact head it reviewed — a rebase or any force-push un-binds it. So the approver
    approves the PR at its live head; if the head moved after an earlier approval, it needs a
-   fresh one (the SHA-binding half of [verify-don't-relay](EXPLANATION.md#verify-dont-relay)).
+   fresh one (the SHA-binding half of [verify-don't-relay](EXPLANATION.md#verify-dont-relay--a-claim-is-not-evidence-until-you-read-the-artifact)).
    An author cannot self-approve their own control-plane change — it needs the *other*
    control-plane human (ADR 0135).
 3. **Let the pipeline enqueue — do not hand-merge.** Once a current-head approval lands, the
@@ -155,7 +155,7 @@ stand-up registered.
 
    It kills that member's pane and reclaims its inbox/artifacts; the role lease frees by TTL,
    leaving the rest of the crew running. An engine requires `--instance`; a singleton bridge
-   rejects it (the [roster law](EXPLANATION.md#roster-law) kind rule).
+   rejects it (the [roster law](EXPLANATION.md#the-roster-law--singleton-bridges-vs-a-fungible-engine) kind rule).
 2. **Retire the whole crew:**
 
    ```bash