fix: strip Scroll to Text Fragment anchors in link checks

[zeitlinger]

Summary

• Adds remap rules to strip Scroll to Text Fragment anchors (#:~:text=...) from GitHub blob URLs before lychee tries to verify them
• Applied to both repo-specific (build_remap_args) and global (build_global_github_args) remaps

Context

Scroll to Text Fragment anchors are a browser-only feature — they highlight text on the page but don't correspond to any HTML element ID. Lychee can't verify them in static HTML.

Without this fix, the "other fragments → raw.githubusercontent.com" remap rule catches these URLs first and redirects them to raw content, where fragment validation fails because #:~:text=extendedAgent isn't a valid anchor.

The consuming repo's lychee.toml already has a remap to strip this specific fragment, but it never fires because CLI --remap args from flint match first (first-match-wins).

Observed in open-telemetry/opentelemetry-java-instrumentation CI — the link works locally because build_remap_args skips when on the base branch.

Test plan

• Verify CI passes on this PR
• After merging, confirm open-telemetry/opentelemetry-java-instrumentation link-check passes (and the repo can remove the workaround remap from its lychee.toml)

[Copilot]

Pull request overview

Updates the lychee link-check remap rules so GitHub “Scroll to Text Fragment” anchors (#:~:text=...) are stripped from /blob/ URLs before verification, avoiding false failures caused by remap precedence and fragment validation limitations in static HTML.

Changes:

• Add a repo-specific /blob/ remap rule that strips #:~:text=... fragments and remaps to the PR head branch.
• Add a global GitHub /blob/ remap rule that strips #:~:text=... fragments for all repositories.
• Update inline documentation/comments to reflect the new remap ordering.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The repo-specific line-anchor remap only matches #L<digits> at end of URL (#L[0-9]+$). GitHub also generates range fragments like #L10-L20; those won’t match rule (1) and will fall through to the “other fragments → raw.githubusercontent.com” rule, where lychee still can’t verify the fragment. Update this rule (and the analogous /tree/ rule) to also match range anchors (e.g., #L[0-9]+(-L[0-9]+)?$ or similar) so they get stripped instead of remapped to raw.

[zeitlinger]

Fixed — changed the repo-specific blob and tree rules from #L[0-9]+$ to #L[0-9]+.*$ to match range fragments like #L10-L20, consistent with the global remap. Added a same-repo range test case (links.sh#L6-L10) to cover this.