fix(tests): make Athena S3 prefix tests self cleaning to avoid flaky CI reruns

[Chaitanya-0310]

Fixes #5971

What's going on

test_clear_partition_data and test_hive_truncate_table both start with the same assumption that their S3 test prefix is empty before they do anything:

assert len(s3_list_objects(s3, base_uri)) == 0

That's what's actually failing in CI, not the partition-clearing logic itself (that part of the test never even runs once this assertion trips). Here's a real failure from the logs:

https://github.com/SQLMesh/sqlmesh/actions/runs/32524629055/job/96906313004

FAILED ...test_clear_partition_data[[query]athena] - AssertionError: assert 3 == 0
...4 rerun in 1147.41s...

Why it happens

Turns out the S3 prefix these tests write to isn't as "fresh" as the test assumes. It's built in conftest.py like this:

engine_adapter.s3_warehouse_location = os.path.join(
    connection_config.s3_warehouse_location,
    f"testrun_{testrun_uid}",
    request.node.originalname,
)

testrun_uid stays the same for the whole pytest session, and originalname is just the test's function name so a single test keeps hitting the exact same S3 prefix across every pytest rerunfailures retry in that run. If a first attempt gets as far as ctas() and then fails afterward for some unrelated, transient reason (Glue/Athena metadata lag, etc.), whatever it wrote to S3 just sits there. The retry hits that same prefix, and its very first assertion fails deterministically because nothing ever cleaned up after the failed attempt. That lines up exactly with what the log shows: 3 leftover files, all under src_table/, which is only ever written by the ctas() call earlier in the test.

Worth calling out: this isn't a bug in _clear_partition_data itself. That logic is checked further down in the test and never gets reached.

The fix

Added a small s3_delete_objects helper next to the existing s3_list_objects one, and call it right before the "prefix should be empty" assertion in both tests. So instead of just hoping the prefix is clean, the test makes sure it is. Should make both tests self-healing against this exact class of flake.

I left test_clear_partition_data_multiple_columns alone it doesn't have this "must start empty" assertion, it just compares before/after counts, so it isn't hit by this issue.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable) — not applicable
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO