Empty Dataset in DID Cache Isn't properly aborted

[gordonwatts]

Describe the bug
A request for running on a dataset that has no files, and the DID look up is in the cache, seems to submit and hang, rather than reporting (somewhere) there are no errors.

To Reproduce
Steps to reproduce the behavior:

1. Run the command uvx atlas-mc-scanner decays mc23_13p6TeV:mc23_13p6TeV.561231.MGPy8EG_A14N23LO_HAHM_ggHZdZd_mumu_600_0p005.deriv.DAOD_LLP1.e8577_e8528_a934_s4370_r16083_r15970_p6619_tid429700882_00 13

Screenshots
You'll get a hang at the terminal:

The dashboard seems to hang as well:

And if you look at the transform's file summary:

And, finally the errors from the detailed log:

The job basically never finishes.

[gordonwatts]

Interesting - that dataset is actually invalid - it is has one too many "0"'s in the command line there! So how does SX know about a bad dataset name?????

Let's try a bad dataset name, and see how it works... Yes, can be reproduced!

1. uvx atlas-mc-scanner decays mc23_13p6TeV:mc23_13p6TeV.561231.MGPy8EG_A14N23LO_HAHM_ggHZdZd_mumu_600_0p005.deriv.DAOD_LLP1.e8577_e8528_a934_s4370_r16083_r15970_p6619_tid429700000882_00 13
2. uvx servicex cache list - find the cache line with 0 files processed - that will be the failed run.
3. uvx atlas-mc-scanner decays mc23_13p6TeV:mc23_13p6TeV.561231.MGPy8EG_A14N23LO_HAHM_ggHZdZd_mumu_600_0p005.deriv.DAOD_LLP1.e8577_e8528_a934_s4370_r16083_r15970_p6619_tid429700000882_00 13 - This will cause the hang that we are seeing above.

[ponyisi]

Subcase of #927