I have solved the probem! There are two problems really. One is a bug in the STM32CubeProgrammer software and the other a lack of validation.
The first problem is that the CubeProgrammer fails to find the loader file which is evidenced by the error:
"FlashLoader 0x cannot be loaded"
when one connects to the MCU. The program can read the MCU details including its ID (0x450 in this case) but then doesn't find the correct file 0x450.stldr. The problem and workaround were outlined in this article:
https://stackoverflow.com/questions/78850472/stm32cubeprogrammer-flash-loader-cannot-be-loaded
I copied the file 0x450.stldr to 0x and on subsequent launch of CubeProgrammer, the error disappeared. Not only that, I could now flash the firmware as well. I don't know whether this affects the Windows version as well, but I was using the latest Linux version of STM32CubeProgrammer, downloaded only yesterday. I would request that STM fix this bug please.
The second problem was that CubeProgrammer does not validate .hex files, but instead treats then as a binary file. This is what led to the device getting incorrectly flashed in the first place. In older and now deprecated tools such as DFuSe, one had to convert from .hex to .bin, but I was under the impression that CubeProgrammer can process either .bin or .hex files directly, although I could not find any confirmation of this. Given my experience, evidently, depite claiming to encompass all of the features neccessary for accessing and flashing MCU's in one package, I could not find a function to convert .hex to .bin and a copy of the deprecated DFuSe was rather difficult to find although I came across it eventually.
Evidently, files still need to first be converted to .bin with DFuSe. Once that was done, fixing the problem was fortunately a simple matter of flashing the firmware again using the .bin file. It would have been helpful to at least pop up a warning when a user specifies a .hex file that a conversion to .bin is neccessary and actually provide a feature to carry out the conversion without having to spend a lot of time searching for a copy of the deprecated software which, it seems, can only be found on a 3rd party website.
After the fimware was flashed again uing the .bin file and the device physically disconnected from the SWD interface, it worked as expected and can now be put into DFU mode if required as well.
I appreciate that the software is made available for free and am grateful for that, but it would be helpful if these issues could be addressed by STM.
