fix(cli): don't crash issue commands on a null network in config.json

[rsnetworkinginc]

PR body — rsnetworkinginc → entrius/gittensor

Branch: fix/issues-cli-null-network (commit d9e0491, in WSL /root/gtn-pr)

Base: test

Title: fix(cli): don't crash issue commands on a null network in config.json

Summary

resolve_network() reads the config-file fallback with

config_network = config.get('network', '').lower()

When ~/.gittensor/config.json contains "network": null (hand-edited, or written by an
external tool), the key exists, so the .get() default is never used — None comes back
and None.lower() raises AttributeError. _resolve_contract_and_network() calls this on the
startup path of every issue command, so gitt issues list, gitt submissions, gitt vote,
gitt admin … all die with a raw traceback instead of falling back to the default network.

The miner-side resolver already guards this exact access — miner_commands/helpers.py
_resolve_endpoint checks if config_network and config_network.lower() in NETWORK_MAP: — so
today the two CLIs disagree on the same config file: gitt miner post works, gitt issues list
crashes.

Reproduction

$ cat ~/.gittensor/config.json
{"network": null}

$ gitt issues list
Traceback (most recent call last):
  ...
  File "gittensor/cli/issue_commands/helpers.py", line 628, in resolve_network
    config_network = config.get('network', '').lower()
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'lower'

After the fix, the same config resolves to the documented default:

$ gitt issues list        # resolves to finney default, command proceeds

(Repro verified against origin/test @ f70007c with HOME pointed at a scratch dir.)

Fix

Guard the access with (config.get('network') or ''), and apply the same guard to the
ws_endpoint fallback label on the line below (config.get('network', 'custom') has the same
None hole — the network name attached to a custom endpoint would silently become None).
This matches the miner helper's existing behavior, so both resolvers now treat a
null/absent network identically.

Tests

New TestResolveNetwork class in tests/cli/test_cli_helpers.py:

• test_null_network_falls_back_to_default — {"network": null} → finney default (crashed before)
• test_null_network_with_ws_endpoint_uses_endpoint — null network + ws_endpoint → endpoint with custom label (crashed before)
• test_recognized_config_network — {"network": "test"} still resolves via NETWORK_MAP
• test_empty_config_falls_back_to_default — no keys → finney default

uv run pre-commit run --all-files                          # all hooks Passed
SKIP=pytest uv run pre-commit run --all-files --hook-stage pre-push   # pyright Passed, vulture Passed
uv run pytest tests/ -q                                    # 964 passed