[BUG] Repo scan ignores 35-day window — `since` filters by `updated_at`, not `closed_at`

[plind-junior]

Description

The repo-centric issue scan isn't actually respecting the 35-day lookback window. In gittensor/validator/issue_discovery/repo_scan.py (around line 211), _fetch_closed_issues calls GET /repos/{repo}/issues with since=<35 days ago>, assuming that limits results to issues closed in the last 35 days.

It doesn't. GitHub's since parameter filters by updated_at, not closed_at. So any old closed issue that gets a comment, label, or reaction in the last 35 days shows up in the scan, even if it was closed years ago.

Steps to Reproduce

Run this against any active repo:

gh api "/repos/ggml-org/llama.cpp/issues?state=closed&since=$(date -u -d '35 days ago' +%Y-%m-%dT%H:%M:%SZ)&per_page=100" \
  --jq '.[] | select(.closed_at < "2025-01-01") | {number, closed_at, updated_at}'

You'll see issues closed back in 2023 / 2024 showing up, because something nudged their updated_at recently.

Expected Behavior

Only issues actually closed within the last PR_LOOKBACK_DAYS should make it into the scan.

Actual Behavior

Ancient closed issues leak into Phase 2 and get classified as Case 2 / Case 3. That pollutes credibility scoring, eats into the REPO_SCAN_*_CAP lookup budget on stale stuff, and — because it depends on who commented when — different validators can end up with different views of the same miner in the same round.

Environment

• OS: Linux
• Python: 3.12
• Commit: main @ 9c9860f

Additional Context

REST has no server-side closed_at filter, so a quick fix is to filter client-side after the response comes back:

in_window = [
    i for i in issues
    if i.get('closed_at') and _parse_iso(i['closed_at']) >= since_dt
]

Happy to open a PR if that sounds like the right direction.

[bitloi]

@plind-junior Thanks for your bug report.