fix: prefer configured network over stale ws_endpoint in miner PAT commands

[MkDev11]

Summary

_resolve_endpoint() in gittensor/cli/miner_commands/helpers.py checks ws_endpoint before the configured network, so a stale ws_endpoint silently overrides a named network the user set. When both keys are present in ~/.gittensor/config.json, gitt miner post and gitt miner check connect to the wrong chain.

PR #1035 fixed the same precedence bug for issue commands (resolve_network() in issue_commands/helpers.py, lines 660–662), but the miner PAT command helper was not updated.

Fix: reorder the config-fallback checks in _resolve_endpoint() so a recognized network (finney, test, local) wins over ws_endpoint. Unrecognized config network values still fall back to ws_endpoint as before.

Related Issues

Closes #1198

Type of Change

• Bug fix

Testing

• Tests added/updated

test_config_recognized_network_beats_stale_ws_endpoint — regression: network=finney + ws_endpoint=ws://127.0.0.1:9944 now resolves to NETWORK_MAP['finney']; returned the stale endpoint before the fix.

test_config_test_network_beats_stale_ws_endpoint — regression: same for network=test.

test_unrecognized_config_network_falls_back_to_ws_endpoint — compatibility: unrecognized config network still lets ws_endpoint win.

test_rpc_url_beats_everything, test_network_flag_beats_config, test_ws_endpoint_used_when_no_config_network, test_default_finney_when_nothing_configured — full precedence ladder covered.

Full suite: uv run pytest tests/ -v → 1495 passed.

Checklist

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

[alpurkan17]

Nice fix! The precedence logic looks clean and follows the same pattern as #1035. Tests cover both regression cases (recognized network beats stale ws_endpoint) and the fallback for unrecognized config networks. Good catch on the config key typo reference too — that would've been confusing during review. 🚀

[alpurkan17]

Thanks for the fix. One concern: this manually reimplements the precedence logic that already exists in issue_commands/helpers.py:resolve_network (fixed in #1035). That function properly handles config_network beating ws_endpoint, so we end up with the same logic in two places.

A simpler approach worth considering: delegate _resolve_endpoint directly to resolve_network, which is what #1242 does — single source of truth, less maintenance burden, and guarantees consistent behavior across all CLI commands.

No blocking objection, just flagging the DRY concern.