BANZAI seems to be producing NaNs for L1FWHM as well as missing values

[talister]

Some recent data declined in quality (clouds rolled in) towards the end of the block, resulting in BANZAI producing NaNs in addition to it's previous behavior of not inserting the L1FWHM keyword if the astrometric fit failed:

FILENAME                             TRACKNUM REQNUM DATE-OBS              OBJECT FILTER L1FWHM
elp1m006-fa08-20240815-0406-e91.fits 2028186 3617621 2024-08-16T08:20:54.584 2024 OY2 w 2.403
elp1m006-fa08-20240815-0407-e91.fits 2028186 3617621 2024-08-16T08:21:10.887 2024 OY2 w ___
elp1m006-fa08-20240815-0408-e91.fits 2028186 3617621 2024-08-16T08:21:27.193 2024 OY2 w ___
elp1m006-fa08-20240815-0409-e91.fits 2028186 3617621 2024-08-16T08:21:43.648 2024 OY2 w NaN
elp1m006-fa08-20240815-0410-e91.fits 2028186 3617621 2024-08-16T08:21:59.810 2024 OY2 w NaN

These should be trapped at Frame creation time and the -99.0 default value inserted.

[talister]

Plot thickens somewhat as the e91/BANZAI Frame entry has FWHM=None although the original -e91.fits has NaN:

In [489]: Frame.objects.filter(filename__contains='elp1m006-fa08-20240815-0409').values_list('frametype', 'fwhm')
Out[489]: <QuerySet [(91, None), (6, nan), (92, nan), (6, nan)]>

Original files with NaNs for reference (now replaced in the DB):

      elp1m006-fa08-20240815-0409-e92.fits: nan
      elp1m006-fa08-20240815-0410-e92.fits: nan
      elp1m006-fa08-20240815-0411-e92.fits: nan
      elp1m006-fa08-20240815-0412-e92.fits: nan
      elp1m006-fa08-20240815-0413-e92.fits: nan
      elp1m006-fa08-20240815-0417-e92.fits: nan