Handle single resultant case in integral non-linearity correction

[schlafly]

The integral non-linearity code doesn't handle images with only a single resultant. We should try to handle that case.

The code wants to make an initial slope estimate so that it can figure out how to correct for the INL in each read of a resultant, since the INL varies quite quickly with count level. That initial slope estimate requires that more than one resultant exist. My nominal plan would be to handle that single result case by assuming zero slope around here:
https://github.com/spacetelescope/stcal/blob/main/src/stcal/linearity/linearity.py#L446-L454
Alternatively we could do something like disabling the INL correction for single resultants entirely, bailing out around
https://github.com/spacetelescope/stcal/blob/main/src/stcal/linearity/linearity.py#L564-L567

@t-brandt , do you have an opinion here?

[karlhillx]

Took a look at this. The single-resultant case actually throws an IndexError on line 448 rather than a div-by-zero — n_unsaturated gets floored to 2, so lastvalidresultant is 1, but mean_read_resultant only has one entry.

Cleanest fix I see is to short-circuit ngroups == 1 to the existing simple group-by-group path, same as the ilin_coeffs is None branch. That sidesteps the reconstruction entirely instead of feeding it a made-up zero slope. The other option you mention — assuming zero slope — only differs for a single resultant that averages several reads, and I'd rather not guess which behavior you want there. Which do you prefer? Happy to put up a PR with a test for the single-group case either way.

[schlafly]

Short-circuiting ngroups == 1 is fine. It's a little sad not to try to correct an exposure with [[1]] as the read pattern, which should be simple---we just need to skip trying to estimate the slope. But this kind of exposure is really not one we should ever encounter in operations and so the goal is to do something that is simple and sane and less to try to do the right thing.