Harden DTS manifest transfer logic to check for errors.

[jeff-cohere]

It's happened a few times that the DTS successfully transfers a payload, generates a manifest, and then attempts to transfer the manifest but fails. I observed this in several transfers before having addressed all the issues mentioned in #214 .

Since these issues have been addressed, I haven't noticed this, but I'm not yet convinced that it couldn't be an issue. Certainly the ongoing bot storm continues to have effects on network reliability, so we might need a more elaborate mechanism to address this issue if we observe it again.

[jeff-cohere]

Okay, I've just observed this failure again:

{"time":"2026-06-05T22:41:45.152785077Z","level":"INFO","msg":"Transfer c7806475-c8d5-4462-805a-364d0ba5b98d: finalizing"}
{"time":"2026-06-05T22:41:45.582241135Z","level":"DEBUG","msg":"GET: https://transfer.api.globusonline.org/v0.10/submission_id"}
{"time":"2026-06-05T22:41:46.546021507Z","level":"DEBUG","msg":"POST: https://transfer.api.globusonline.org/v0.10/transfer"}
{"time":"2026-06-05T22:41:46.932204473Z","level":"ERROR","msg":"transferring manifest file: Submission ID '00000000-0000-0000-0000-000000000000' not found (SubmissionNotFound)"}

So it seems that a zero UUID is returned by the transfer submission ID when something (?) goes wrong. We should add a check for this condition.