Post-merge edit detection incorrectly penalises issues auto-closed by merged PRs

[spider-yamet]

Description

The anti-gaming post-merge edit detection in _collect_issues_from_prs (gittensor/validator/issue_discovery/scoring.py) incorrectly flips solved issues to closed when the issue was auto-closed by the merged PR.

When a PR merge auto-closes a linked issue, GitHub sets the issue's updated_at to the close timestamp, which is always slightly after merged_at. The current check issue.updated_at > pr.merged_at treats this normal auto-close as a post-merge edit, causing:

• solved_count to be decremented and closed_count to be incremented
• The issue to be classified as "closed" instead of "solved"
• Credibility to drop (e.g. from 100% to 0.0%)
• The valid_solved_count to not be incremented (bypassed by the early continue)

Steps to Reproduce

1. A miner opens an issue on a tracked repository
2. A PR referencing the issue (e.g. Fixes #N) is merged
3. GitHub auto-closes the issue, setting updated_at to the close timestamp (a few seconds after merged_at)
4. The validator scores issue discovery for the miner
5. The issue is classified as "closed" instead of "solved"

Real example: entrius/gittensor-ui#172 — PR merged at 19:05:04Z, issue auto-closed at 19:05:06Z. The 2-second gap triggers the penalty.

Expected Behavior

Issues auto-closed by a merged PR should count as "solved" for credibility and eligibility purposes. The post-merge edit detection should only penalise issues whose content was genuinely edited after both the merge and close events.

Actual Behavior

The issue is reclassified from solved to closed, reducing the miner's solved_count and inflating closed_count. This lowers credibility and can prevent the issue from contributing to valid_solved_count, impacting eligibility.