fix(signals): single-source isCodeFile via isSourcePath and add .kts

[RealDiligent]

Summary

Hardens src/signals/test-evidence.ts ahead of the gittensory-engine extraction tracked in #2277 by introducing canonical isSourcePath (symmetric with isTestPath) and delegating path-matchers.ts / engine.ts isCodeFile to it. Also closes the .kts gap where Gradle Kotlin-script source escaped missing-tests gate signals while isTestPath already recognized .kts test files.

Closes #2277

Scope

• Conventional Commit-style title; focused classifier change + regression tests only.
• Follows CONTRIBUTING.md; no UI/API/schema/migration changes.

Validation

• npm test -- test/unit/test-evidence.test.ts test/unit/local-branch-file-classifiers.test.ts test/unit/path-matchers.test.ts test/unit/signals.test.ts
• CI validate-code + validate green on this PR

Safety

• No secrets, auth, API, UI, or migration changes.
• Behavior-preserving for previously-covered extensions; adds .kts source and consolidates duplicate matchers.

[superagent-security]

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

[loopover-orb]

Tip

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

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-07 05:51:52 UTC}

7 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR consolidates duplicate isCodeFile/isTestFile logic across engine.ts and path-matchers.ts by introducing a canonical isSourcePath in test-evidence.ts, and fixes a real gap where .kts (Kotlin script) source files were recognized as tests by isTestPath but not as code by isCodeFile, letting them escape the missing-tests gate. The refactor is behavior-preserving for previously-covered extensions (cs/swift/groovy/kt/kts/scala/java/go/sql moved into the core isSourcePath set, php/cpp/cc/c/h/hpp/m/vue/svelte/astro/dart remain in path-matchers' EXTENDED_SOURCE_EXTENSION with the generated-dart exclusion still applied), and engine.ts now imports isCodeFile/isTestFile from path-matchers instead of defining local copies. Regression tests cover the new .kts recognition and confirm test files with source-like extensions (Tests.kts, Spec.groovy, Tests.cs, Tests.swift) are still excluded, matching CI passing on this commit.

Nits — 5 non-blocking

• src/signals/path-matchers.ts:24 — the 'fix(signals): exclude generated Dart part files from code scoring #3724' reference in the comment is only meaningful to someone who looks it up; consider a short inline note of what that PR established (generated Dart part-file convention) rather than just the number.
• The isSourcePath/EXTENDED_SOURCE_EXTENSION split relies on both test-evidence.ts and path-matchers.ts staying manually in sync (no shared list or type-level guarantee) — worth a comment or lightweight test asserting the two extension sets are disjoint so a future edit can't accidentally duplicate an extension across both.
• review-enrichment/src/analyzers/test-ratio.ts's SOURCE_EXTS and the Python gittensor-score-preview.py scorer both hand-maintain their own copies of the source/test extension lists (per their own comments) — this PR doesn't update them for .kts source, so those two analyzers still have the same gap this PR just fixed in the main signals path; worth a follow-up issue if not already tracked.
• Consider whether review-enrichment/src/analyzers/test-ratio.ts and packages/gittensory-mcp/scripts/gittensor-score-preview.py should get the same .kts-as-source fix in a fast-follow, since their extension lists are explicitly documented as manual copies of the src/signals logic this PR just changed.
• A one-line test asserting isSourcePath and EXTENDED_SOURCE_EXTENSION don't overlap would guard against future drift now that the source-extension definition is split across two files.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2277
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 (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 219 registered-repo PR(s), 59 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 219 PR(s), 0 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 219 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.

_{🟩 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

[loopover-orb]

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

[RealDiligent]

Follow-up PR #3921 (CI green, Gittensory approve) was auto-closed because it linked maintainer-reserved #2235. The MCP .kts classifier parity fix is ready on \RealDiligent:fix/mcp-iscodefile-kts-parity. Could a maintainer please open a contributor-eligible upstream tracking issue for this follow-up so we can re-open with \Closes #…?