[coverage] Conformance findings: CLOUDFETCH-017

Start with TestCloudFetchDecompressionFailureSurfacesAsDecompressionError in the coverage PR diff under tests/, then trace the CloudFetch download and decompression path in databricks-sql-go. Compare the intended behavior with reference PR #419. Done means the caller receives an error identifying decompression, including decompress, decompression, or lz4, and the connection remains usable afterward.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-go) is fixed, then flips green as a tripwire.

Findings

• CLOUDFETCH-017 [thrift]: A CloudFetch chunk downloaded with HTTP 200 but a corrupt compressed body fails in the decompressor, yet the cause is re-wrapped into an unrelated row-indexing/Arrow message ("row number 0 is not contained in any arrow batch ... unexpected EOF"), so the caller cannot identify decompression as the cause (PECOBLR-3537)
  • failing test: TestCloudFetchDecompressionFailureSurfacesAsDecompressionError (see the coverage PR diff under tests/)

Reproduce & Expected

CLOUDFETCH-017 — When a CloudFetch chunk downloads SUCCESSFULLY (HTTP 200) but its body is not a valid compressed frame, the driver fails inside its decompressor rather than on the HTTP status. The error the caller receives MUST identify DECOMPRESSION as the cause. This is the one CloudFetch failure mode that is not an HTTP failure: every cloudfetch_ scenario fails the request, so the driver never reaches its decompression step. Because a corrupt payload is a permanent condition (unlike an expired link), a fresh presigned URL does not help -- the driver retries the same URL, exhausts its budget, and must then surface a decompression error. Regression guard: before the fix the raw decompressor error was propagated untagged and re-wrapped downstream into an unrelated row-indexing message ("row number not contained"), so the true cause was invisible to the caller and the failure was misclassified in telemetry as a generic error. The contract is that the cause survives to the caller as a decompression error, and that the process/connection stays usable afterwards.

Reproduce:

• A result large enough to be delivered via CloudFetch external links.

Expected (per the shared spec):

• full assertion contract:

result:
- error:
    contains:
    - decompress
    - decompression
    - lz4
- connection_usable_after_error: true
protocol:
  thrift:
  - cloud_downloads_min: 1
  sea:
  - cloud_downloads_min: 1

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-go/pull/419 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1015