fix(spec-tools): load txs that carry no signature material

[danceratopz]

Fixes the json-loader CI failure on this branch: 136 cases, all test_bad_v_r_s, all failing with AssertionError: secret_key or signer must be set (run 28782882693) from ethereum#2924.

Bug

Filled state tests store a tx whose signature is deliberately invalid with no signature material at all: the state-test fixture format cannot express explicit v/r/s (the blockchain format carries them inside txbytes), so these fixtures rely on expectException. The json_loader feeds that tx to the CLI t8n verbatim. The new CLI parser builds a testing Transaction and RLP-encodes it for the returned body; RLP serialization auto-signs a tx whose v/r/s were never set and hits assert signing_key is not None because there is no secretKey and the sender EOA carries no key. The previous parser (t8n_types.Txs.parse_json_tx) defaulted each missing component to 0x00 and let the fork reject the invalid signature.

Fix

_normalize_tx_json now defaults v/r/s to zero when a tx carries none of v/r/s/secretKey, restoring the previous parser's behavior: the tx executes with an invalid signature and is rejected, which is exactly what these fixtures assert.

Verification

• The filled bad_v_r_s.json fixture is byte-identical between this branch and forks/amsterdam (only the provenance URL differs), so the failure is purely in the loader path and this fix cannot change any fixture output.
• Filled tests/frontier/validation/test_transaction.py::test_bad_v_r_s locally into tests/json_loader/fixtures for Homestead and Prague and ran pytest tests/json_loader: all cases pass with this fix and reproduce the CI assertion without it.
• The new branch only triggers for a tx with no signature material at all; signed txs and secretKey-carrying txs take exactly the same path as before, so behavior for every other input is unchanged.