Slim and redesign the main PR signals table (cut low-value rows, redesign Gittensor context, explore Points Forecast)

[JSONbored]

Part of #5095.

Context

The main signals table (buildPublicPrPanelSignalRows in src/signals/engine.ts) has 7 fixed rows today: Linked issue, Related work, Change scope, Validation posture, Contributor workload, Contributor context, Gate result (plus an optional 8th "Improvement" row, covered by a separate sub-issue). Direct maintainer feedback: the rows actually acted on are Linked issue, (Code) review/Gate result, Related work, and Contributor context -- Change scope, Validation posture, and Contributor workload are described as "meh/redundant/pointless," rarely looked at.

The "Contributor context" row specifically

contributorContextPanelResult (src/signals/engine.ts) currently renders:
```ts
if (!confirmedMiner) {
return { result: "❌ No public Gittensor match", evidence: `${githubLink}; not a blocker.`, action: "No action." };
}
```
This is a real, confirmed bug in spirit: the icon (❌, a hard-failure signal everywhere else in this table) directly contradicts the evidence text right next to it ("not a blocker"). Every non-Gittensor contributor -- the overwhelming majority of PR authors on most repos -- sees a red X on their own PR for something that was never supposed to read as a failure.

What's already available for a redesign

GittensorContributorSnapshot (src/gittensor/api.ts) already carries, per repo, everything needed for a genuinely useful row:
```ts
repositories: Array<{
repoFullName: string;
credibility: number;
totalScore: number;
baseTotalScore: number;
...
}>
```
No new data plumbing is needed to show a real per-repo credibility/score number for a confirmed contributor -- it's already fetched, just not surfaced in this row today.

Points Forecast (more exploratory)

RepositoryRecord.registryConfig (RegistryRepoConfig in src/types.ts) already carries emissionShare, labelMultipliers (per type-label weight), and maintainerCut. The Gittensor API's per-PR records (GittensorContributorSnapshot.pullRequests[]) already carry score/baseScore/tokenScore for PRs Gittensor has already evaluated (i.e. after merge). A genuine PRE-merge "projected points if this PR lands with its current label" forecast would need to combine the repo's own multipliers with the PR's current type-label -- this is a real, new calculation, not just re-surfacing existing data, and needs validation against Gittensor's actual scoring algorithm (external, not something gittensory controls) before committing to an exact formula.

Requirements

• Decide which of Change scope / Validation posture / Contributor workload to cut vs. keep, with a real rationale per row (not just "the maintainer said so" -- look at what each one actually measures and whether it's redundant with something else already visible, e.g. Validation posture vs. the existing coverage/test-evidence collapsible).
• Redesign "Contributor context" → "Gittensor": result is ✅ (confirmed contributor) or a neutral/grey state (not a public Gittensor match) -- NEVER ❌. Evidence collapses to one line: the GitHub username (already hyperlinked, unchanged) plus the contributor's per-repo credibility/score from GittensorContributorSnapshot.repositories[], linked to their Gittensor profile.
• Prototype (not necessarily ship) a "Points Forecast" row using the repo's emissionShare/labelMultipliers and the PR's current type-label, clearly caveated as an estimate, never implying a guarantee (public-safe wording constraints apply -- no "reward"/"payout" language).

Deliverables

• Updated buildPublicPrPanelSignalRows + contributorContextPanelResult (renamed) with full test coverage, including the ❌→✅/neutral fix as its own clearly-flagged bug fix (this part should ship even if the rest of the table redesign takes longer).
• A written recommendation on which low-value rows to cut, with example before/after table renders.
• A Points Forecast prototype write-up: formula sketch, data sources, and an explicit call on whether it's ready to ship or needs more validation first.

Expected outcome

A shorter, higher-signal-density table where every row is something a maintainer actually looks at, and no row visually contradicts its own evidence text.

Open questions for the maintainer

• Final call on which rows to cut/keep.
• Whether Points Forecast ships in this pass or stays a prototype for a later one.

[linear-code]

JSO-3669