tests: compatibility-data-snapshots/ is no longer anonymously readable (403), breaking test_historic_storage_formats

Steps to reproduce

test_historic_storage_formats downloads its datasets from neon-github-public-dev, which is no longer anonymously readable. Every object under compatibility-data-snapshots/ returns 403:

$ for f in 2024-07-18-pgv16 2025-02-07-pgv17-nogenerations 2025-04-08-pgv17-tenant-manifest-v1; do
    u="https://neon-github-public-dev.s3.eu-central-1.amazonaws.com/compatibility-data-snapshots/$f.tar.zst"
    printf '%s -> HTTP %s\n' "$f.tar.zst" "$(curl -sS -o /dev/null -w '%{http_code}' "$u")"
  done
2024-07-18-pgv16.tar.zst -> HTTP 403
2025-02-07-pgv17-nogenerations.tar.zst -> HTTP 403
2025-04-08-pgv17-tenant-manifest-v1.tar.zst -> HTTP 403

$ curl -sS "https://neon-github-public-dev.s3.eu-central-1.amazonaws.com/compatibility-data-snapshots/2025-02-07-pgv17-nogenerations.tar.zst"
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>8XXSEH2K5MV9HV9M</RequestId>...</Error>

This looks bucket-wide rather than specific to that prefix. A different prefix — the Allure report URL linked from the comment at test_runner/regress/test_tenant_detach.py:156 — returns 403 as well:

$ curl -sS -o /dev/null -w '%{http_code}\n' \
    "https://neon-github-public-dev.s3.amazonaws.com/reports/pr-3232/debug/3846817847/index.html"
403

Same result via the path-style endpoint and via s3.amazonaws.com, so it is not a region/endpoint mistake.

Expected result

compatibility-data-snapshots/ is anonymously readable, as #8423 intended when it introduced the test against "a new path in the public S3 bucket".

Actual result

test_historic_storage_formats fails for every dataset matching the run's PG version. Because test_compatibility.py:531 does not call raise_for_status(), the 263-byte AccessDenied XML body is fed straight into the zstd decompressor, so the failure surfaces as a corrupt-archive error rather than an HTTP error:

FAILED test_runner/regress/test_compatibility.py::test_historic_storage_formats[debug-pg17-dataset1]
  - zstd.ZstdError: zstd decompress error: Unknown frame descriptor
FAILED test_runner/regress/test_compatibility.py::test_historic_storage_formats[debug-pg17-dataset2]
  - zstd.ZstdError: zstd decompress error: Unknown frame descriptor

That message sends you looking at zstd/tarfile rather than at a permissions problem, which cost us a while to track down.

Environment

Running the test_runner/regress suite from a fork on GitHub-hosted runners, debug build, DEFAULT_PG_VERSION=v17. No AWS credentials configured, which is why the anonymous read matters. dataset0 self-skips on a v17 run; dataset1 and dataset2 fail.

Only these two tests are affected — test_create_snapshot passes, and test_backward_compatibility / test_forward_compatibility / test_versions_mismatch self-skip cleanly without COMPATIBILITY_NEON_BIN.

Logs, links

• #8423 added the test, and notes the path "is populated by hand", so there is no workflow that could regenerate these artifacts.
• Nothing else appears to serve them: no Wayback Machine capture of any of the three URLs, and a GitHub code search for compatibility-data-snapshots returns only copies of test_compatibility.py itself, no mirror of the data.

Ask

Could the compatibility-data-snapshots/ prefix (or the bucket) be made anonymously readable again? If the bucket was intentionally locked down and that is not going to be reverted, publishing these three artifacts somewhere durable — a GitHub release asset on this repo, for example — would let forks and external contributors run the suite without AWS credentials.

Separately, and independent of the access question: adding r.raise_for_status() at test_compatibility.py:531 would turn any future failure here into an honest HTTP error instead of a misleading zstd one. Happy to send a PR for that piece if it is welcome.