fix(engine): cap predicted-gate's local linked-issue extractor at the canonical 50 (#6771)

[shin-core]

Summary

predicted-gate-engine.ts's local extractLinkedIssueNumbers documents itself as matching "the canonical src/db/repositories.ts extractor" — but that one caps at MAX_LINKED_ISSUE_NUMBERS = 50 (extractLinkedIssueNumbersWithOverflow stops collecting once reached), while the local copy collected every match uncapped.

• A PR body can easily fit 50+ short closing references inside the 20,000-char truncation this runs on, so the miner's local pre-submission linked-issue set could diverge from what the real maintainer-side gate computes — undermining the prediction-parity guarantee this module exists for.
• Applied the same 50 ceiling. Kept as a local literal (not an import) because this module is deliberately host-import-free; the constant carries a comment cross-referencing MAX_LINKED_ISSUE_NUMBERS in src/db/repositories.ts as the drift guard, per the issue's stated options.
• No other behavior change: the code-span rejection, same-repo-only qualified/URL rules, dedup, and positive-integer filter are untouched.

Closes #6771

Test plan

• REGRESSION: a body with 66 distinct same-repo closing references spanning all three supported forms (30 bare #N, 18 qualified owner/repo#N, 18 full-URL) now yields exactly 50 linked issues — and the result stays deduped and all-positive (the cap truncates, it doesn't corrupt). Added to the existing predicted-gate-engine-coverage.test.ts rather than a new file.
• predicted-gate-engine-coverage + predicted-gate-engine-branch-coverage green (31 tests).
• npm run test --workspace @loopover/engine green — 588 pass / 0 fail.
• npm run typecheck clean.
• Coverage: every changed line is exercised (the file's one uncovered line, 707, is pre-existing and outside this diff).

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.64%. Comparing base (fa8f577) to head (0fe3e99).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6857   +/-   ##
=======================================
  Coverage   93.64%   93.64%           
=======================================
  Files         684      684           
  Lines       68193    68194    +1     
  Branches    18707    18707           
=======================================
+ Hits        63858    63859    +1     
  Misses       3350     3350           
  Partials      985      985           

Flag	Coverage Δ
shard-1	43.68% <100.00%> (+<0.01%)	⬆️
shard-2	36.84% <100.00%> (+0.01%)	⬆️
shard-3	32.84% <100.00%> (+0.21%)	⬆️
shard-4	34.86% <50.00%> (+0.02%)	⬆️
shard-5	31.69% <100.00%> (+0.14%)	⬆️
shard-6	45.43% <100.00%> (-0.31%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...opover-engine/src/signals/predicted-gate-engine.ts	100.00% <100.00%> (ø)

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-17 09:06:15 UTC}

2 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This is a narrow, correctly-scoped fix that caps the local `extractLinkedIssueNumbers` extractor in predicted-gate-engine.ts at 50 to match the canonical `MAX_LINKED_ISSUE_NUMBERS` ceiling in `src/db/repositories.ts`, closing a real prediction-parity gap where local pre-submission counts could diverge from the maintainer-side gate. The fix applies `.slice(0, MAX_LINKED_ISSUE_NUMBERS)` after dedup, which is the correct point to truncate since it caps distinct issue numbers rather than raw regex matches, and the added regression test exercises all three reference forms (bare, qualified, URL) with 66 distinct refs collapsing to exactly 50. The PR is tied to and closes #6771, and the change is minimal, well-commented, and test-verified.

Nits — 4 non-blocking

• The canonical extractor's cap behavior (does it truncate post-dedup like this one, or stop collecting mid-scan pre-dedup, potentially yielding a different subset of 50 on ties) isn't verifiable from this diff alone — worth confirming the truncation semantics match exactly, not just the count.
• predicted-gate-engine.ts is already a large file (per the external brief, ~964 lines); no action needed here but a candidate for future decomposition.
• Consider a brief inline note in the test confirming which 50 of the 66 refs are expected to survive (e.g., first-50-in-scan-order) to guard against future changes to iteration order silently altering which issues get linked.
• If `src/db/repositories.ts`'s cap ever changes, this literal will silently drift again — consider a light CI check (e.g., a shared test fixture or lint rule) since the code comment alone won't catch a future divergence.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6771
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 49 registered-repo PR(s), 29 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 49 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, JavaScript, Solidity, Dart, Python, CSS, PHP, Rust
• Official Gittensor activity: 49 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

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

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.