Split the test_invalid_json CI job into its three cases

[adamtheturtle]

Refs #3540.

test_invalid_json.py::TestInvalidJSON::test_invalid_json is the critical path of the Test workflow at 51 minutes, where the next slowest pattern is 10 minutes and 61 of the other patterns finish under 2. Since the workflow is serialised on concurrency: vuforia_credentials, that one job sets how long the shared lock is held.

Measuring the gaps between test results in that job's log:

tests:  71
span:   48.3 min
gaps > 5s:  55 gaps, totalling 48.2 min
gaps <= 5s: 0.1 min

Six seconds of work, forty-eight minutes of sleeping — wait_fixed(wait=10) in RETRY_ON_TRANSIENT_VWS_FAILURE, ten seconds per 429.

What this changes

The single test parametrised over seven bodies becomes the three cases it was conflating, each its own ci_pattern:

• test_not_json — b"a"
• test_not_an_object — b"[]", b'"hello"', b"5", b"null", b"true"
• test_not_utf_8 — a JSON object encoded as latin-1

The shared body moves to a _assert_body_rejected helper, so the assertions are unchanged and stated once. The critical path becomes the five-value case, so that job should fall to roughly 36 minutes and a run from ~52 to ~37.

The secrets wrap

Adding patterns pushes past the 100 available credentials files, where SECRET_INDEX=$((JOB_INDEX % 100)) makes two jobs share a database. Rather than add to that, the pattern list is now ordered so every entry from index 100 on is one which never parametrises over the Real Vuforia backend:

100 -> tests/mock_vws/test_requests_mock_usage.py
101 -> tests/mock_vws/test_respx_mock_usage.py
102 -> tests/mock_vws/test_flask_app_usage.py
103 -> tests/mock_vws/test_healthcheck.py
104 -> tests/mock_vws/test_docker.py
105 -> README.rst
106 -> docs/

I confirmed each of those collects zero Real Vuforia parametrisations. This also fixes an overlap that exists on main today, where test_target_validators.py at index 100 shares a database with test_query.py::TestContentType at index 0.

Caveat on the expected gain

The saving assumes Vuforia rate limits per database. Each job gets its own credentials file and therefore its own database, so if that holds, sharding really does divide the waiting. If the limit is per account, the 429s move rather than disappear. I have not established which it is — #3540 records this, along with the larger point that pacing requests or using exponential backoff would attack the cause rather than divide it across jobs.

Verification

• pytest-check-partition passes, so the patterns still partition the suite exactly.
• tests/mock_vws/test_invalid_json.py --skip-real: 160 passed, 80 skipped.
• All pre-commit and pre-push hooks pass.

No behaviour change, so no newsfragment.

🤖 Generated with Claude Code