fix(engine): dedupe provider signals per target in computeProviderTrackRecords

[shin-core]

What & why

Closes #8876.

packages/loopover-engine/src/calibration/provider-track-record.ts's computeProviderTrackRecords
built a stancesByTarget map that collapses a provider's multiple signals on one targetKey to the
latest vote, but the aggregation loop iterated the raw signals array — incrementing
signals/decided/shared/consensus once per signal instead of once per distinct
(provider, targetKey) pair. Since loadLiveProviderTrackRecords reads raw audit rows with no dedup,
a provider re-reviewing the same PR (common after a new push) had its precision/agreement stats
inflated proportionally to its revote count, while its consensus stance reflected only the last vote.

Change

Dedupe to one signal per (provider, targetKey) pair with latest-vote-wins — the same last-write
semantics stancesByTarget already applies — before the aggregation loop, so each distinct pair
contributes exactly once.

Validation

• New test: a provider's earlier pass + later fail on one target contributes signals: 1
  (not 2), resolving to the latest fail (so precision stays 1), while distinct pairs still each
  count — on both the engine's own suite and the Codecov-graded vitest suite.
• Bug-catch verified: reverting the aggregation loop to the raw array fails exactly the new assertion
  in both runners.
• 100% patch coverage on the dedup path.

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[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 93.87%. Comparing base (ba596a5) to head (11883ff).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8954      +/-   ##
==========================================
+ Coverage   90.56%   93.87%   +3.31%     
==========================================
  Files          96      807     +711     
  Lines       22490    80439   +57949     
  Branches     3884    24388   +20504     
==========================================
+ Hits        20367    75509   +55142     
- Misses       1945     3561    +1616     
- Partials      178     1369    +1191     

Flag	Coverage Δ
backend	95.15% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...er-engine/src/calibration/provider-track-record.ts	100.00% <100.00%> (ø)

... and 710 files with indirect coverage changes

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-26 14:40:38 UTC}

3 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This is a narrow, well-targeted bug fix: `computeProviderTrackRecords` previously aggregated over the raw `signals` array while `stancesByTarget` already deduped per (provider, targetKey) with latest-vote-wins, so a provider's repeat votes on one target inflated `signals`/`decided`/`shared`/`consensus` proportionally to revote count. The fix builds `dedupedByProviderTarget` with the same last-write semantics and aggregates over its values instead, which is consistent with how `stancesByTarget` is already built and consumed later in the same function. Tests in all three suites (engine unit, workspace package, and the dist-based test) exercise the exact revote scenario and assert the pre-fix counts would have been wrong, and the PR closes the linked issue #8876.

Nits — 3 non-blocking

• provider-track-record.ts: the dedup key `${signal.provider} ${signal.targetKey}` uses a plain space separator, so a provider id containing a space could theoretically collide with a different (provider, targetKey) pair — a delimiter unlikely to occur given providers are opaque ids per the module's own doc comment, but worth a `\0`-style separator for defense in depth.
• The failed 'Contributor trust — Contributor flagged for review' check is unrelated to this diff's content and not a code defect.
• Consider using a tuple-safe key (e.g. JSON.stringify([provider, targetKey]) or a null-byte separator) in provider-track-record.ts for the dedup map to eliminate any theoretical collision risk.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#8876
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: 39 registered-repo PR(s), 23 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 39 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff dedupes signals into a Map keyed by (provider, targetKey) with latest-vote-wins semantics and switches the aggregation loop to iterate that map instead of the raw signals array, directly matching the issue's requirement. Tests in two suites assert that repeated same-provider votes on one target count once toward signals/decided/consensus while resolving to the latest vote.

Review context

• Author: shin-core
• 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: 39 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

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

• Re-run LoopOver review

[loopover-orb]

Held for manual review: the gate and required CI are green, but GitHub reports this pull request's mergeable state as unstable because a non-required check or status is not passing, so LoopOver will not auto-merge. A maintainer can resolve the failing check or review and merge manually. This is an automated maintenance action.