fix(content-lane): canonicalize issue-body path tokens (Closes #9667)

[wondercreatemaster]

Summary

• checkContentLaneDeliverable now canonicalizes each extractPathTokens candidate before matchesSpec, mirroring classifyRegistryPrScope's matchesPattern helper.
• mentionedPath on the "missing" verdict still returns the original issue-body token (public-comment text stays verbatim).
• All-lowercase path behaviour is unchanged; paths that match no spec pattern still return not-applicable.

Issue: #9667

Why prior attempts failed

Previous PRs (#9788, #9889, #9893, #9926, #9930) shipped the correct code fix but were auto-closed by content_lane_deliverable_missing: the issue body itself names the example path registry/subnets/foo.json, so a body closing-keyword link to this issue armed the deliverable gate against a code-only PR. Adding that registry file alongside TypeScript changes then trips surface_lane_reject (mixed-files). This PR delivers the code/tests only.

Test plan

• npx vitest run test/unit/content-lane-registry-logic.test.ts (174 passed)
• Coverage on src/review/content-lane/registry-logic.ts: 100% stmts/branches/funcs/lines
• NODE_OPTIONS=--max-old-space-size=8192 npm run typecheck
• npx vitest run test/unit/check-manifest-drift-script.test.ts test/unit/loopover-focus-manifest.test.ts

[loopover-orb]

Caution

🛑 LoopOver review result - reject/close recommended

_{Review updated: 2026-07-31 17:11:25 UTC}

2 files · 1 AI reviewer · 1 blocker · CI green · clean

🛑 Suggested Action - Reject/Close

Review summary
This fixes checkContentLaneDeliverable so issue-body path tokens are canonicalized before matching against spec patterns (lowercased + `./`-stripped + `\`→`/`), mirroring classifyRegistryPrScope's existing matchesPattern helper — a mixed-case issue body path like `Registry/Subnets/Foo.json` previously failed to match the lowercase-only compiled RegExp and silently returned not-applicable, hiding a genuinely undelivered issue. mentionedPath correctly returns the original uncanonicalized token so the public PR comment still quotes the issue body verbatim, and the changedFiles side already canonicalized so this closes an asymmetry. Tests cover the mixed-case match, the byte-identical lowercase case, and the not-applicable no-match case, all tracing directly to the new code path.

Nits — 3 non-blocking

• The PR description names five prior closed PR attempts (fix(content-lane): canonicalize the issue-body path token in checkContentLaneDeliverable #9788, fix(content-lane): canonicalize issue-body path tokens in checkContentLaneDeliverable #9889, fix(content-lane): canonicalize issue-body path tokens in checkContentLaneDeliverable #9893, fix(orb): canonicalize issue-body path tokens in checkContentLaneDeliverable (#9667) #9926, orb(content-lane): canonicalize issue-body path tokens in `checkContentLaneDeliverable #9930) for the same fix — worth double-checking none of that history left stray artifacts or partially-applied variants of this canonicalization elsewhere in the file.
• Per the issue-scope policy, confirm this PR itself properly links/closes orb(content-lane): canonicalize issue-body path tokens in `checkContentLaneDeliverable #9667 in a way the deterministic gate recognizes (the description states 'Closes orb(content-lane): canonicalize issue-body path tokens in `checkContentLaneDeliverable #9667' but the gate's own armed-deliverable heuristic is explicitly called out as the reason prior attempts failed — worth verifying this PR doesn't re-trigger that same gate).
• Consider a short comment or test title clarifying why `mentionedPath` intentionally stays uncanonicalized (already partly covered by the code comment at registry-logic.ts:932-934, but the test file's own docstring reiterates this well — good as-is).

Why this is blocked

• No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

Decision drivers

• ❌ Code review — 1 blocker (1 reviewer)
• ❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 33 registered-repo PR(s), 16 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	wondercreatemaster; Gittensor profile; 33 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Review context

• Author: wondercreatemaster
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, Python, TypeScript, Java, MDX, Swift
• Official Gittensor activity: 33 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

LoopOver is closing this pull request on the maintainer's behalf (No linked issue detected). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.