feat(scoring): explain issue-discovery validity floor in score breakdown

[bohdansolovie]

Summary

Adds an issueDiscoveryHistoryMultiplier component to explainScoreBreakdown, matching the existing merged-PR history breakdown pattern.

When linked-issue scoring is active and contributor history is observed, miners now see whether their valid-solved count and issue credibility meet the upstream floors (MIN_VALID_SOLVED_ISSUES, MIN_ISSUE_CREDIBILITY). When history is unobserved, the breakdown stays neutral and explains that the floor is not enforced yet.

Why

buildScorePreview already applies the issue-discovery validity multiplier and emits issue_discovery_validity_floor blockers, but the score breakdown never explained that gate. This closes the same visibility gap that #1453 and recent merged-history breakdown work addressed for other floors.

Test plan

• npx vitest run test/unit/score-breakdown.test.ts
• Neutral when issue-discovery history is unobserved
• Full when valid solved + credibility meet upstream floors
• Blocked with actionable lever when below floors
• Component included in the multiplier contract test

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-01 04:26:22 UTC}

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

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The change adds an `issueDiscoveryHistoryMultiplier` explanation beside the existing history-floor breakdown and wires it into `explainScoreBreakdown`. The implementation follows the existing component shape and keeps the final summary/lever sanitization path intact. The main remaining risk is edge coverage: partial issue-history inputs and inactive linked-issue inputs are not exercised, so the new wording relies on upstream invariants that are not made explicit here.

Nits — 7 non-blocking

• nit: `src/services/score-breakdown.ts:143` treats either missing issue-history field as fully unobserved; confirm `buildScorePreview` never emits partial issue history, or make the neutral summary identify which field is absent.
• nit: `test/unit/score-breakdown.test.ts:123` covers both floors passing and both floors failing, but not the branch where valid-solved history passes and issue credibility alone fails.
• Add a focused test where `validSolvedIssues` meets the floor and `issueCredibility` is below it, so the right-hand side of the floor check is covered on the real `buildScorePreview` path.
• Add or document an invariant for `linkedIssueMode: "none"` with observed issue-history fields, because `issueDiscoveryHistoryBreakdown` currently phrases below-floor observed history as zeroed without checking the mode itself.
• Pull request duplicates other open work — Check for an existing pull request or issue covering this change and coordinate or consolidate before continuing.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
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.
Change scope	❌ 8/20	High review scope from cached public metadata (size label size:M; no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR; address the blocker before review.
Contributor workload	✅ 10/10	Author activity: 136 registered-repo PR(s), 76 merged, 24 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bohdansolovie; Gittensor profile; 136 PR(s), 24 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: bohdansolovie
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: Python, C++, JavaScript
• Official Gittensor activity: 136 PR(s), 24 issue(s).
• Related work: Titles/paths share 10 meaningful terms. (PR #1982)
• Related work: Titles/paths share 6 meaningful terms. (PR #1935)
• Related work: Titles/paths share 7 meaningful terms. (PR #1978)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Explain no-issue PR.
• Review top overlaps.
• Add a concise scope and risk note.
• Fix the blocker.
• Triage stale or unlinked PRs.
• 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.
• 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

[JSONbored]

Review comment mentions things I'd like fixed before I can approve this:

The main remaining risk is edge coverage: partial issue-history inputs and inactive linked-issue inputs are not exercised, so the new wording relies on upstream invariants that are not made explicit here.