Two folders in project prj_9aupbftc return NoSuchKey on every file download (job-records, job-descriptions)

Hi Dewey support,

Every file in two folders of our LinkUp project prj_9aupbftc fails to download. The signed URLs returned by the file-listing API come back HTTP 404 with a 137-byte S3-style XML error:

NoSuchKey Key not found

Affected folders (every file we tried; re-verified today, 2026-06-12):

prj_9aupbftc__fldr_czs87iepuw96dmpdc — job-records, 250 files, ~62 GB.
Example: job-records_0_0_0.snappy.parquet (external_id dwllv2_019ebd51-a06f-7a41-bc42-a1d44e49308c, listed size 275,473,407 bytes)
prj_9aupbftc__fldr_ic4qtmhz4e88zf3hd — job-descriptions, 2,251 files, ~595 GB.
Example: job-descriptions_0_0_0.snappy.parquet (external_id dwllv2_019ebd52-6ee4-7ee3-91d3-514406b050e5, listed size 237,808,325 bytes)
What we verified:

The listing endpoint (api.deweydata.io/api/v1/external/data//files) returns HTTP 200 with complete file metadata for both folders — only the download URLs (downloads.deweydata.io/api/v2/downloads/...) return 404 NoSuchKey.
Reproduced with curl, Python httpx, and the deweypy client (deweypy saves the 137-byte XML error body as the .parquet file and then retries forever on the size mismatch).
Same API key, same time: the other two folders in the project download fine — prj_9aupbftc__fldr_m8o6nxzcq79zv77h8 (structured-fields) and prj_9aupbftc__fldr_t9twyabo6oiuzyooj (employer-type-reference) — so this is folder-specific, not an authentication issue.
Possibly relevant: the broken folders' files have modified_at timestamps of 2026-05-12, while the working folders' files are from 2026-06-06. It looks like the underlying storage objects from May 12 may have been expired or purged while the listing metadata remained.
Could you re-provision/re-materialize the underlying objects for these two folders so the download links work again? Happy to provide more details if useful.