The Windows program G7ToWin works to check the HWID in preboot mode. Soft-bricked devices which show the logo splash screen almost invariably have preboot available so even though they aren't detected in Mass Storage Mode by a PC, they are shown in Device Manager as "GARMIN Device" and will be recognized by some programs like G7ToWin. There is a warning in the Cure3 thread initial post about using correct fw and also a link to the thread to help in finding the device's actual HWID:
Quote Originally Posted by kunix View Post
Here is a special firmware patcher for creating cure firmwares. Patched firmwares enter the mass storage mode immediately, without going through the normal booting process ( e.g. they don’t display “Loading maps…” and so on). That’s why they don’t crash or hang up because they don't try to load corrupt files, therefore, they can be used for curing. It works even if your device was formatted into NTFS.

WARNING
  1. Don't use GarminCure3.exe if you don't know how to enter pre-boot mode. Entering pre-boot is neccessary to flash firmwares after CURE firmware has been flashed.
  2. Don't flash GVN and Kenwood devices with the CURE firmware, as they don't have a real pre-boot mode very frequently.
  3. Download latest Garmin USB Drivers to your PC if you don't already have them loaded: [Only registered and activated users can see links. ].
  4. Check your device's HWID and compare it to the firmware you intend to use to avoid making a minor problem a permanent one by using an incompatible fw. Read here how to check: [Only registered and activated users can see links. ].
...........................................................
(My emphasis in red added to above quote).

But as you said, what's done is done ... that's if in fact, 'done' by you however. To check further and maybe eliminate the possibility of an incompatible firmware causing the hard-bricking, here's some more information. To flash the wrong fw to it you'd have had to make an intentional or accidental change to the 'safe-naming' of the RGN file automatically given by GarminCure3.exe. Let's say for instance that your device has the MTK chip with HWID 1106. Say also that you used the HWID 0972 firmware to make the Cure. The program would have made the cure RGN named "097201000630.RGN" (where '630' is denoting use of Version 6.30 in that example). When that's loaded to Updater.exe it detects "01000" in the file name so when the device is connected in preboot it will query the device to check it's actual HWID. If the device has HWID different from 0972/972, Updater will report "No Updates Available For Device" and not attempt to flash it. However, if certain change is made to the RGN file's naming, e.g. "OUT.RGN" or even a single numeral is removed from the central "01000" (e.g. 09720100630.rgn) then that safety check isn't done and the flash is forced. As your flash initiated, regardless that it then failed, either the device indeed matched the fw in HWID, or the RGN safe-naming had been changed.

So if you're quite certain that you didn't change the default naming of the cure RGN file, the problem may not at all be of your doing. Updater's flash not finishing and the subsequent message "System Software Missing" can also mean that the device's main flash memory chip was already damaged, i.e. failing but still partially functioning, which could explain why the device appeared 'soft-bricked' initially and could still attain preboot. It's not uncommon for a failing chip to be finally pushed over the edge by an attempted flash. Regardless of course,for practical purposes the 1490 would still be a paper-weight only good for parts whether the chip is physically kaput or just been inappropriately flashed.

Still worth trying to drain all charge from it. Good luck.