fix(scoring): exclude maintainer-generated test commits from contributor scoring

[JSONbored]

Part of #4189. Depends on #4197 (the commit-delivery mode is what introduces the actual commit needing exclusion).

Context

#1972's "no-cloud-write boundary" exists to protect contributor/miner scoring integrity — a miner's score must reflect their own work. #4197 deliberately creates a narrow, maintainer-only exception to that boundary (a maintainer, not the contributor, authorizes gittensory to write a commit onto the PR branch). That exception is only safe if the resulting commit can never be silently counted as part of the contributor's scored contribution — otherwise a maintainer generating tests would inadvertently inflate the PR author's Gittensor points for code they didn't write, which is the exact failure mode the boundary was built to prevent, just via a different path.

This issue is a verification-and-fix, not a known bug: whatever computes a PR's scored diff size/contribution weight for Gittensor points needs to be checked for whether it already excludes bot/app-authored commits (e.g. it might already be diff-by-commit-author rather than raw base..head diff, in which case this issue is a fast confirmation) or whether it needs a new exclusion rule added.

Requirements

• Identify exactly where contribution size/diff weight is computed for Gittensor scoring purposes (candidates: src/scoring/, src/gittensor/, wherever PR review outcomes feed the points model) and determine whether it measures base...head diff wholesale or sums only commits authored by the PR's actual contributor.
• If it already excludes non-author commits: add a regression test proving a gittensory-authored test commit does NOT change the PR's computed score, and close this out as verified, not just assumed.
• If it does NOT already exclude them: add commit-author-based exclusion (the GitHub App's own bot identity is a stable, verifiable signal — same identity already used to post the unified review comment) so a maintainer-added commit is subtracted from whatever diff the scoring model measures.
• Whatever mechanism is chosen must also apply retroactively-safely — i.e. not require re-scoring already-merged historical PRs, only affect PRs scored from this change forward.
• Document the finding (excluded-already vs. needed-a-fix) clearly in the implementing PR, since this is exactly the kind of boundary-integrity detail that should be traceable later.

Deliverables

• A definitive answer, backed by a passing test, on whether gittensory-authored commits already are or now are excluded from contributor scoring.
• If a fix was needed: the exclusion mechanism, plus a regression test using a synthetic bot-authored commit.

Expected outcome

A maintainer using @gittensory generate-tests with commit delivery never inflates the PR author's own scored contribution — the maintainer-only exception to the no-cloud-write boundary stays narrow and auditable in both directions (who can trigger it, and what it does to scoring), not just the trigger side.

Resources / examples

• #1972 — the original boundary rationale ("Generating tests server-side would break the contributor boundary")
• src/scoring/model.ts, src/scoring/preview.ts, src/scoring/pending-pr-scenarios.ts (starting points to trace the actual scoring computation — not yet confirmed which one owns diff-size measurement)

Effort

S-M — likely a fast confirmation if scoring already keys off commit authorship; M if a new exclusion needs to be built.

[linear-code]

JSO-3233

[JSONbored]

Investigation finding, changing this issue's scope from the original text:

Traced the actual scoring computation. gittensory does not compute or determine the authoritative Gittensor score for any PR — src/scoring/model.ts fetches and mirrors the upstream Bittensor subnet's own constants.py (via GITTENSOR_UPSTREAM_REPO/GITTENSOR_UPSTREAM_REF), and computeLocalScorerTokens (src/signals/local-scorer.ts, called only from an MCP preview tool at src/mcp/server.ts:2676) is a local, miner-side preview so a miner can self-estimate before submitting. The real, authoritative score is computed by external validators reading the merged PR directly from GitHub — gittensory has no code-level lever over that computation at all.

This means the original fix ("add commit-author exclusion to gittensory's own scoring pipeline") doesn't apply — there's no gittensory-owned scoring pipeline to patch. The real risk is narrower and structural: if #4197's commit delivery mode pushes a maintainer-authored commit onto a confirmed-miner's PR branch, an external validator scoring that merged PR would see the maintainer's added lines as part of the merged diff, inflating what looks like the miner's own contribution.

Revised fix, folded into #4197 rather than as a separate scoring-pipeline change: gate commit delivery mode on whether the PR's author is a confirmed Gittensor miner (reusing the existing confirmed_miner/getCachedOfficialMinerDetection detection already used throughout the authorization system) — block/decline direct-commit delivery for a confirmed-miner PR (falls back to comment-only, or the separate follow-up-PR mode, which doesn't touch the original scored PR's diff at all), unrestricted for any other PR author (internal maintainer PRs, non-scored self-host installs, etc.).

Flagging this clearly since it's a real integrity/economics judgment call, not a routine implementation detail — proceeding with this as the conservative default, documented here for review.