Fix stokes passed as integer string to imsubimage in 4D mosaic path

[EOakes]

In the channel-by-channel ndim==4 path of mosaic_aligned_data, imsubimage was being called with stokes='0' (an integer index as a string), but it requires a polarization label like 'I'. Fixed by reading the stokes labels from the coordinate system of myia_sum, which is already open at that point.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 6.28%. Comparing base (3d909c2) to head (24234ac).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
phangsPipeline/casaMosaicRoutines.py	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #349      +/-   ##
=========================================
- Coverage    6.28%   6.28%   -0.01%     
=========================================
  Files          38      38              
  Lines       15229   15232       +3     
  Branches     3660    3660              
=========================================
  Hits          957     957              
- Misses      14258   14261       +3     
  Partials       14      14              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[thomaswilliamsastro]

Seems reasonable to me. I wonder why we haven't found this before? Any ideas @EOakes? I would have thought this should affect any mosaics we're trying to run...

[EOakes]

Seems reasonable to me. I wonder why we haven't found this before? Any ideas @EOakes? I would have thought this should affect any mosaics we're trying to run...

I think it's the fact that a) the cube has to be big enough to trigger the memory-managed path, and b) the input images need to be 3D so adddegaxes fires - in previous testing for #323, I may have overlooked the second condition.

[thomaswilliamsastro]

@EOakes OK! It's clear to me that we should probably just keep the 4 axes around through postprocessing so we save a bunch of time adding them back in and ripping them out, so this seems like a good point to start