fix: use GraphQL-only issue PR lookup

[MkDev11]

Summary

REST issue/PR search matched the issue number as a bare text token, which can surface unrelated PRs whose title/body happen to contain that number. Rather than layering regex filtering on top of that imprecise source, this PR removes _search_issue_referencing_prs_rest and makes find_prs_for_issue rely only on GraphQL cross-reference timeline data.

Behavior now:

• No PAT: returns an empty list instead of risking wrong REST search data, and the human CLI output tells users to set GITTENSOR_MINER_PAT.
• PAT + GraphQL empty: returns the correct empty cross-reference set.
• PAT + GraphQL error: returns empty after the existing GraphQL retry/backoff path.

Validator scoring remains unaffected because find_solver_from_cross_references already uses GraphQL-only cross-reference data and never used the REST fallback.

Related Issues

Closes #773

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other (describe below)

Testing

• Tests added/updated
• Manually tested

Ran:

• uv run pytest tests/utils/test_github_api_tools.py tests/cli/test_issue_submission.py -> 82 passed
• uv run ruff check gittensor/utils/github_api_tools.py gittensor/cli/issue_commands/helpers.py tests/utils/test_github_api_tools.py tests/cli/test_issue_submission.py -> passed

Checklist

• Code follows project style guidelines
• Self-review completed
• Changes are documented (if applicable)

[anderdc]

The premise is right (REST bare-token search returns false positives) but the fix keeps the broken path and adds a regex on top. Cleaner: delete _search_issue_referencing_prs_rest and have find_prs_for_issue short-circuit on GraphQL alone.

• No-PAT CLI users get an empty list instead of a wrong one — wrong data is worse than no data for an inspection command.
• PAT users on GraphQL-empty get correct empty (the cross-reference set is genuinely empty, which is what GraphQL just told us).
• PAT users on GraphQL-error get empty after the existing retry/backoff in execute_graphql_query / get_github_graphql_query (max_attempts=8 in the latter) — no need for a second data source.

Issue body confirms scoring isn't affected (find_solver_from_cross_references uses GraphQL only and never falls through), which bounds the blast radius. Drop the regex helper, the filter, and the two new test classes; keep the existing find_prs_for_issue tests and confirm they still pass under the simpler cascade.

Optional UX improvement: surface a "set GITTENSOR_MINER_PAT" hint in gitt issues submissions when no PAT is set, so the empty-list case is actionable instead of silent.

[MkDev11]

The premise is right (REST bare-token search returns false positives) but the fix keeps the broken path and adds a regex on top. Cleaner: delete _search_issue_referencing_prs_rest and have find_prs_for_issue short-circuit on GraphQL alone.

• No-PAT CLI users get an empty list instead of a wrong one — wrong data is worse than no data for an inspection command.
• PAT users on GraphQL-empty get correct empty (the cross-reference set is genuinely empty, which is what GraphQL just told us).
• PAT users on GraphQL-error get empty after the existing retry/backoff in execute_graphql_query / get_github_graphql_query (max_attempts=8 in the latter) — no need for a second data source.

Issue body confirms scoring isn't affected (find_solver_from_cross_references uses GraphQL only and never falls through), which bounds the blast radius. Drop the regex helper, the filter, and the two new test classes; keep the existing find_prs_for_issue tests and confirm they still pass under the simpler cascade.

Optional UX improvement: surface a "set GITTENSOR_MINER_PAT" hint in gitt issues submissions when no PAT is set, so the empty-list case is actionable instead of silent.

just pushed the update, can you please review again?