fix(api): preserve error response body

[hrubymar10]

Summary

When an API request returns a non-2xx status, the resulting log line carries no
information about why it failed:

Error while fetching match summary en: Url=https://<api-host>/v1/sports/en/sport_events/od:match:<id>/summary|ResponseCode=NotFound|Response=

Response= is always empty, so a wrong endpoint and a genuinely missing entity
are indistinguishable in logs.

The API does return a diagnostic body on every error:

<response response_code="NOT_FOUND"><action>Wrong endpoint</action><message>Desired API endpoint not found</message></response>

RestClient reads that body into requestResultString and then discards it: the
non-2xx branch calls RequestResult.Failure(...) without passing rawData, even
though Failure() already declares the parameter. This restores it.

Note that the ignoreUnsuccessfulStatusCode branch a few lines above already
passed the body to Success() — the failure path was simply inconsistent with
the success path next to it.

Verification

The two 404 cases the API distinguishes, confirmed against a running instance:

Case	Response
Valid route, entity absent	404 with an entity-level message
Unknown route	404 with <action>Wrong endpoint</action>

Both are indistinguishable in logs today; with this change the <action> and
<message> reach CommunicationException.Response.

45/45 tests pass; no new compiler warnings.

Blast radius

Diagnostics only — one line, one file. Request behaviour, caching, retries and
threading are all unchanged; the only difference is that a field which was
always empty is now populated.

[stetinatomas-oddin]

Lenses run: correctness/invariants · security · API-contract/backward-compat, with test-coverage as a standing pass. → 0 findings; nothing to anchor inline.

Reviewed at 4ab7611 (refs/pull/65/head), read from fetched objects rather than a working tree.

Three things worth being sure of on a two-line fix, all clean:

1. rawData is actually populated on this path. requestResultString is assigned unconditionally at RestClient.cs:178, and every route into the non-2xx branch at :182 passes through it with no intervening return. ReadAsStringAsync yields "" rather than null on an empty body, so the new argument is never null and carries the diagnostic whenever the API sends one.

2. No new leak surface. The access token travels as a request header (RestClient.cs:35), never in the URL or the body, so an error response cannot echo it back. And the same string is already written unconditionally to the log one line earlier (RestClient.cs:180) — this routes an already-logged value into the exception, it does not introduce a new class of data into logs.

3. Nothing downstream changes shape. Failure()'s rawData already defaulted to "" (RequestResult.cs:41), so no caller could have been branching on null. RawData is consumed only at RestClient.cs:79 and :128, both feeding CommunicationException.Response and its ToString() (CommunicationException.cs:42) — which is exactly the field this fix exists to fill. No test asserts on either. The call site uses named arguments, so parameter order is not in play.

Trailing newline is a harmless normalization. CI green.

Manual review by Tomáš: LGTM.

Co-Authored-By: Claude Opus 5