fix: use total solved_count for issue credibility instead of valid_solved_count

[edwin-rivera-dev]

Summary

• Pass both solved_count and valid_solved_count to check_issue_eligibility
• Use solved_count for credibility formula (matches docs and OSS pattern)
• Use valid_solved_count for the minimum count gate (unchanged behavior)
• Also update evaluation.issue_credibility to reflect the corrected value

Closes #642

Problem

check_issue_eligibility receives valid_solved_count and uses it for both the eligibility
gate and the credibility formula. The credibility formula should use ALL solved issues, not
just valid ones. This matches the OSS credibility pattern which passes all merged PRs to
calculate_credibility and separately counts valid ones.

Test plan

• Miner with 10 solved (7 valid) + 2 closed gets credibility 0.91 not 0.875
• Eligibility gate still requires 7 valid solved issues

[anderdc]

Fix is correct — the bug is real, the math in the issue is verified, and the approach matches the existing OSS credibility pattern cited in #642. Just requesting a test before merge.

Why a test matters for this one:

This is a scoring-formula change with direct impact on every miner's issue credibility. The bug was introduced by a silent parameter collapse during a previous refactor (solved_count and valid_solved_count got merged into one slot), and without a test locking down the corrected behavior, the same class of regression could happen again on the next refactor.

Suggested test shape (~15 lines in tests/validator/test_issue_discovery_scoring.py or similar):

@pytest.mark.parametrize(
    'solved_count,valid_solved_count,closed_count,expected_credibility,expected_eligible',
    [
        # Issue #642 example: 10 total solved, 7 valid, 2 closed
        # Credibility uses total (10), eligibility gate uses valid (7)
        (10, 7, 2, pytest.approx(10 / 11, abs=1e-3), True),
        # Valid count below threshold → not eligible regardless of credibility
        (10, 6, 2, pytest.approx(10 / 11, abs=1e-3), False),
        # Zero solved → credibility 0, not eligible
        (0, 0, 2, 0.0, False),
        # All solved counts equal (no low-token solvers) → fix is no-op for this case
        (7, 7, 2, pytest.approx(7 / 8, abs=1e-3), True),
    ],
)
def test_check_issue_eligibility_uses_total_for_credibility_valid_for_gate(
    solved_count, valid_solved_count, closed_count, expected_credibility, expected_eligible
):
    is_eligible, credibility, _ = check_issue_eligibility(solved_count, valid_solved_count, closed_count)
    assert credibility == expected_credibility
    assert is_eligible is expected_eligible

That locks down:

• The 10/7/2 example from the issue body
• The valid-below-threshold case (eligibility fails even with good credibility)
• The zero-input edge case
• The solved_count == valid_solved_count case (no-op for miners without low-token solvers)

Parametrizes cleanly, covers the branches, and documents the intent for future refactorers.

Everything else looks good — scope is minimal (4 code lines), approach matches the OSS pattern, signature change is local, and the caller is updated correctly. Once the test lands, ready to merge.

[edwin-rivera-dev]

Hi, @anderdc
Thanks for your feedback. Could you review again please?

[anderdc]

ci failed

[edwin-rivera-dev]

Hi, @anderdc
CI Error has been resolved. Please let me know your recommendation.
Thanks.

[edwin-rivera-dev]

🐛 CI Bug was fixed

Hi, @anderdc
How are you? Please review again and share your opinion.
Thanks.