fix(replay-parse-service): handle plain HTTPError from ballchasing client

[ben4643]

Summary

Fixes prod IndexError: tuple index out of range in parseReplay Celery task that made previously-uploaded replays permanently un-parseable.

_parse_ballchasing assumed ballchasing exceptions had args = (response, body) and used e.args[1]. python-ballchasing actually raises plain requests.HTTPError from raise_for_status() — args is a 1-tuple (message,), so e.args[1] raises IndexError before the duplicate-replay (409) fast-path could run. Every retry of an already-uploaded replay then crashed.

Changes

• New _extract_response_and_body(exc) helper — pulls Response and parsed body off exc.response.
• Replaced the 6 e.args[1] / *e.args references in _parse_ballchasing with (response, body) from the helper.
• Exceptions with no .response (e.g. ConnectionError) now re-raise instead of being silently misinterpreted as a known status code.

Tests

New tests/test_ballchasing_error_handling.py:

• 409 duplicate-replay → fast-path returns existing replay's data, no IndexError
• 400 failed-replay → original exception re-raises (not IndexError)
• 429 rate-limit on get_replay → retries, succeeds on second call
• Unknown exception (ConnectionError, no .response) → propagates unchanged

All 11 tests pass (4 new + 7 pre-existing).

Test plan

• Re-run one of the failing prod task IDs (e.g. dc357bcc-8bcc-4321-bba4-6b66e261c64b) against staging and confirm no IndexError.
• Submit a known-already-uploaded replay and confirm "Replay already parsed " log line appears, followed by successful stats fetch.
• Submit a fresh replay and confirm normal upload path still works.

[gankoji]

I'm not sure I see the point of this - this is cleaning up error handling for the ballchasing path, which at this point is both not active and fully deprecated.