export zip dies at 512mb and takes the whole worker down, 12 days to shutdown Data Export

Do not zip. The zip is a requirement you invented.

Generate a manifest per account: manifest.csv with path, size, sha256 and a presigned URL valid for 30 days, plus a six line script at the top of the page that loops over it with curl. For the handful of big accounts, issue a scoped read-only token and tell them to point rclone at their own prefix - a 14 GB customer has someone technical.

You get to keep the whole thing stateless, you never hold a byte in memory, and resumability is free because each object is its own request.

If you insist on a zip, stream it and turn compression off. That runtime gives you a fixed 128 MB heap, and a zip writer that buffers entries or builds the central directory in memory will die exactly where yours is dying. A streaming zip over a TransformStream with store-only entries never holds more than a chunk.

Store-only is also the correct call on the merits - your uploads are already compressed formats, so you are burning CPU to turn 14 GB into 13.8 GB.

Run it offline, once per account, and stop treating it as an endpoint. 240 runs is a laptop, a for loop and a weekend. Write each zip straight into R2 with multipart upload, then email a link. No memory limit, no request timeout, no user waiting on a spinner, and if run 137 fails you rerun run 137.

Bump the memory in wrangler.toml, there is a limits block for exactly this - set memory_mb higher and the problem goes away without rewriting anything.

Whatever you ship, count exports per account and put the number on a page you look at every morning. On mine, 31 of 84 accounts never downloaded anything, and those are precisely the people who email you in March asking whether there is any way to get their data back.