fix: fetch newest cross-references for solver lookup so popular issues find the merged PR

[aliangm]

Summary

_PR_TIMELINE_QUERY in gittensor/utils/github_api_tools.py:412 requested timelineItems(itemTypes: [CROSS_REFERENCED_EVENT], first: 50) — the oldest 50 cross-references on the issue. On any issue that accumulated more than 50 cross-references before the solver PR was opened, the solver's cross-ref event sat past position 50 and got dropped. The merged-PR + closing-numbers filter at github_api_tools.py:1005 then returned [], find_solver_from_cross_references returned (None, None), and the validator at issue_competitions/forward.py:115 cast vote_cancel_issue — refunding the bounty and zeroing the miner who actually did the work.

Switch to last: 50 so the query returns the newest 50 cross-references, matching the pattern already used elsewhere in the same file (RENAMED_TITLE_EVENT, last: 1 at line 108; LABELED_EVENT, last: 5 at line 130). Downstream filtering and the earliest-merged_at tiebreaker are unchanged.

Why this triggers in the wild

Cross-references aren't just miner PRs — every #N mention from any issue, PR, or comment counts: bot pings (Dependabot, CI), review-discussion comments, "see also" mentions from downstream trackers. 50 fills faster than it sounds.

Realistic trigger cases:

• Pre-existing issues that get bountied later. Popular-repo issues often have dozens-to-hundreds of historical cross-refs before a bounty is attached. When a miner finally solves it, the solver PR's event sits at position 60+ chronologically.
• Contested bounties. Multiple miners each open a PR (1 cross-ref each), plus review comments and related-issue mentions during the cycle.

Scope

• One-character change to the GraphQL query string.
• The merged-PR + closing-numbers filter still excludes non-solver mentions; the merged_at ASC sort still picks the earliest closing PR among matches. No behavior change on the happy path.
• Mirror path (solved_by_pr from das-github-mirror) was unaffected; only the legacy timeline-based path was vulnerable. Issue-competitions runs against ALL active on-chain issues regardless of mirror_enabled, so this fix applies broadly.

Related

• Sibling truncation in the same query (not addressed here): [Bug] _PR_TIMELINE_QUERY truncates closingIssuesReferences to 20 nodes for solver lookup #885 — closingIssuesReferences(first: 20) at line 426. Different field, different trigger (a single PR closing >20 issues vs. a single issue accumulating >50 cross-refs).
• Precedent for this class of bug: [BUG] Scoring label lookup drops when LABELED_EVENT falls outside timelineItems(last: 5) #646 — same last: pattern fix for LABELED_EVENT.
• Distinct prior bugs (confirmed not duplicates): Issue bounties cast cancel votes when solver lookup fails (API/rate-limit path) #517 (API/rate-limit failures misclassified as no-solver — a failed API call, not truncated data); [Bug] find_solver_from_cross_references credits wrong solver on multi-PR closing references - latest-merged PR steals bounty #757 (wrong-solver attribution when multiple PRs claim closing — opposite failure mode).

Residual nuance (not in this PR)

last: 50 still loses if an issue accumulates >50 cross-refs after the solver merges (heavy post-merge discussion, regressions filed later that mention #N). Smaller blast radius than the current "old issue with prior history" case. Full correctness needs endCursor pagination — can extend this PR or follow up if preferred.

Test plan

• Existing solver-related unit tests pass (12 passed): pytest tests/utils/test_github_api_tools.py -k "cross_references or solver"
• Manual verification on a tracked issue with >50 historical cross-references, confirming the validator now identifies the solver and votes vote_solution instead of vote_cancel_issue

Fixes #1017