fix(cli): distinguish inconclusive PAT reply from no-response in miner check

[jakearmstrong59]

Summary

Fixes #1406

After #1107, handle_pat_check returns has_pat=True, pat_valid=None on a transient GitHub failure — a validator that has the miner's PAT but couldn't confirm validity because GitHub's /user lookup momentarily failed. The CLI consumer _pat_check_row_category had no branch for that shape, so it fell through to no_response, rendering a healthy validator identically to one that never replied:

• Table mode: shows — no response (contradicting the truthful "retry in a few minutes" reason in the adjacent column).
• --json mode: counted under no_response, excluded from valid, and can flip success to false.

This adds a fifth inconclusive category so the two states are distinguishable. It does not change exit codes or the success = valid_count > 0 rule (cf. the closed #1129 / #542, which were exit-code/success policy for a valid zero result) — it only fixes the categorization of a reply that genuinely arrived. This is the same class of accuracy fix as the merged #724 / #807 in this same file.

Relationship to existing work

• fix: treat transient GitHub PAT identity checks as inconclusive #1107 (merged) added the producer-side pat_valid=None state, touching only validator/pat_handler.py + its test — it never updated the CLI consumer. This PR is that missing consumer-side half.
• [Bug] pat_handler treats transient GitHub /user failures as invalid PATs in validator-side broadcast/check handlers #1106 noted pat_valid=None "fits the existing CLI classification … maps that state to no_response, not invalid_pat." That only establishes the inconclusive reply isn't mislabeled as invalid_pat (true). The defect fixed here is different: it was indistinguishable from no_response (never answered) — lost, operator-actionable information.

Changes

• gittensor/cli/miner_commands/helpers.py
  • New inconclusive branch in _pat_check_row_category, placed after the invalid_pat branch and guarded on has_pat is True so a genuinely silent validator (has_pat=None, pat_valid=None) still resolves to no_response.
  • inconclusive key added to _pat_check_aggregate_counts (auto-surfaces in --json via the existing **counts spread).
• gittensor/cli/miner_commands/check.py
  • inconclusive entry in _PAT_CHECK_STATUS_MARKUP. Required, not cosmetic: the table renders via a bare _PAT_CHECK_STATUS_MARKUP[category] lookup, so a new category without a markup entry would raise KeyError.
• tests/cli/test_miner_commands.py
  • TestPatCheckRowCategory: every category, including inconclusive ≠ no_response, silent-validator → no_response, and missing-keys → no_response.
  • Updated the existing aggregate-counts assertion to include inconclusive, plus a non-collapse test.
  • A categorizer↔markup parity guard (test_every_category_has_table_markup) so a future category addition can't silently reintroduce the KeyError.
  • CLI-level gitt miner check --json integration tests (parity with the sibling miner post test): inconclusive surfaces distinctly, success stays False for an inconclusive-only result, and the table render does not KeyError.

Testing

• pytest tests/ → 892 passed.
• ruff check / ruff format --check → clean.
• Verified the new tests fail against pre-fix code (regression locked).

Scope

Consumer-side categorization only. Out of scope: the validator producer (pat_handler.py, already merged in #1107), exit-code / success-rule changes, PAT-whitespace handling (#1392/#1393), and gitt miner post categorization (different reply shape — PatBroadcastSynapse has no pat_valid field).

[anderdc]

too many tests for a two line change, remove the tests

[jakearmstrong59]

Hi @anderdc, how are you. I've fixed. Thanks for the review.

[jakearmstrong59]

Thanks @anderdc