fix(cli): fail issues submissions when no PAT is set instead of reporting zero

[swengieer0829]

Summary

gitt issues submissions reports a false negative when GITTENSOR_MINER_PAT is not set.

The command lists open PR submissions for a bountied issue via GitHub's GraphQL API, which requires a PAT. When no token is present, find_prs_for_issue returns [] for the falsy token (it cannot query GitHub at all), and submissions treats that empty list as a genuine result — printing success: true, submission_count: 0 and exiting 0. That is indistinguishable from an issue that really has zero open submissions, and in --json mode there is no diagnostic whatsoever (the "No GitHub token found" warning was gated to human mode only).

This is exactly the false-negative the command's own code already guards against for the None GitHub-lookup-failure sentinel (added in #1554):

# None is the GitHub lookup-failure sentinel ... Surface it as an explicit error
# instead of reporting an empty submission list, which would be a false negative
# for monitoring/automation.

The missing-token case is another way the lookup cannot be performed, so it should surface the same way. This change makes fetch_open_issue_pull_requests raise a ClickException when no PAT is set; submissions already routes ClickException through handle_exception, so the error is surfaced correctly in both human and JSON modes (exit 1). This also matches how gitt miner post / gitt miner score already treat a missing PAT, and keeps JSON and human modes in agreement on exit codes (per #724).

Before / After

Command (no GITTENSOR_MINER_PAT in the environment):

$ gitt issues submissions --id 42 --json

Before — false negative, exit 0:

{"success": true, "issue_id": 42, "repository": "owner/repo", "issue_number": 123, "submission_count": 0, "submissions": []}

After — surfaced precondition, exit 1:

{"success": false, "error": {"type": "cli_error", "message": "A GitHub token is required to list submissions. Set GITTENSOR_MINER_PAT and retry."}}

In human mode, the misleading No open submissions available (...) line is likewise replaced by a clear error and a non-zero exit.

Note: end-to-end terminal capture requires a live subtensor connection and a real on-chain bounty issue, so the before/after above is shown as the exact JSON envelopes the command emits. The two added tests assert precisely this behavior and fail on the pre-fix code.

Related Issues

Type of Change

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

Testing

• Tests added/updated
• Manually tested

Added two tests to tests/cli/test_issue_submission.py, mirroring the existing None lookup-failure tests:

• test_submissions_json_missing_token_returns_structured_error — asserts success: false and no submission_count key.
• test_submissions_human_missing_token_errors_instead_of_no_submissions — asserts a non-zero exit and that the misleading "No open submissions available" line is not printed.

Both tests fail on the pre-fix code (the command exits 0) and pass with the fix, so they lock the regression. ruff check, ruff format --check, and vulture are all clean on the changed files.

Checklist

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

[anderdc]

hi please provide before and after screenshots