fix(content-lane): limit registry provider companions

[JSONbored]

Motivation

• The registry surface-model PR classifier allowed an entry submission to carry any number of flat provider files as "allowed companions", which could let extra provider changes ride along without receiving the proper provider-only scrutiny.

Description

• Tighten classifyRegistryPrScope to require providerFiles.length <= 1 when an entry file is present so an entry-submission may have at most one flat provider companion (changed the isEntryPr predicate in src/review/content-lane/registry-logic.ts).
• Update the function documentation to reflect the "at most one provider" rule in the header comment in src/review/content-lane/registry-logic.ts.
• Add a regression unit test in test/unit/content-lane-registry-logic.test.ts that asserts an entry plus two flat provider files is classified as not-direct-submission with directFile null.

Testing

• Ran npx vitest run test/unit/content-lane-registry-logic.test.ts and the unit suite (147 tests) passed.
• Ran npm run typecheck (tsc --noEmit) and it completed successfully.
• Attempted coverage generation with npx vitest --coverage and tests passed but coverage post-processing failed with TypeError: jsTokens is not a function originating in ast-v8-to-istanbul.
• npm audit --audit-level=moderate could not complete in this environment due to an HTTP 403 from the npm audit endpoint.

---

Codex Task

[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 95.38%. Comparing base (9e1c351) to head (f837b19).
⚠️ Report is 4 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1312   +/-   ##
=======================================
  Coverage   95.38%   95.38%           
=======================================
  Files         201      201           
  Lines       21598    21598           
  Branches     7807     7808    +1     
=======================================
  Hits        20601    20601           
  Misses        416      416           
  Partials      581      581           

Files with missing lines	Coverage Δ
src/review/content-lane/registry-logic.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	940ce41	Commit Preview URL Branch Preview URL	Jun 25 2026, 11:05 PM

[gittensory-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review — safe to merge

2 files · 1 AI reviewers · no blockers · readiness 48/100 · CI green · blocked

✅ Approved — safe to merge

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewers, synthesized
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Review load	❌ 8/20	Readiness component derived from cached public PR metadata and labels; size label size:XS.
Validation evidence	❌ 5/25	Cached preflight status is hold.
Open PR queue	❌ 3/10	48 open PR(s), 9 likely reviewable, 39 unlinked.
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 81 PR(s), 261 issue(s).
Gate result	✅ Passing	No configured blocker found.

Nits — 2 non-blocking

• Repository config was not parsed
• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 81 PR(s), 261 issue(s).
• Related work: Titles/paths share 8 meaningful terms. (PR #1427, PR #1489)
• Related work: Titles/paths share 7 meaningful terms. (PR #1537, PR #1546)
• Related work: Titles/paths share 6 meaningful terms. (PR #1391, PR #1392)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Review top overlaps.
• Add scope summary.
• Fix blocker.
• Expect slower review.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Review load = cached public PR metadata such as size labels, changed paths, and preflight status.
• Open PR queue = repo-wide review pressure; it is not a PR quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[JSONbored]

Closing — the condition it guards can't occur. The orchestrator already routes any changed file that isn't the single directFile to manual human review (orchestrator.ts:88-92), so an entry submission with provider companions never auto-adopts today. This patch instead downgrades that case from entry-submission→manual to not-direct-submission→null, which falls through to the generic gate — strictly less content-lane scrutiny — and it's inconsistent with the multi-entry precedent (#1319 routes the analogous bundle to a decisive "mixed-files" close). The current behavior is the safe one.