JP-4151: Give TSO3 x1dints files an S_REGION

[emolter]

Resolves JP-4151

Closes #9910 along with spacetelescope/stdatamodels#602

This PR adds an s_region attribute to the output x1dints files coming from calwebb_tso3. Hopefully this allows these products to be found in MAST queries by target ID or location.

This PR handles this in the very simplest way, by just updating the s_region of the output to be the same as the s_region of the first input file. I don't know of any tso observations where input files should have different sky footprints, but hopefully the code will fail gracefully in that case.

Tasks

• If you have a specific reviewer in mind, tag them.
• add a build milestone, i.e. Build 12.0 (use the latest build if not sure)
• Does this PR change user-facing code / API? (if not, label with no-changelog-entry-needed)
  • write news fragment(s) in changes/: echo "changed something" > changes/<PR#>.<changetype>.rst (see changelog readme for instructions)
  • update or add relevant tests
  • update relevant docstrings and / or docs/ page
  • start a regression test and include a link to the running job (click here for instructions)
    • Do truth files need to be updated ("okified")?
      • after the reviewer has approved these changes, run okify_regtests to update the truth files
• if a JIRA ticket exists, make sure it is resolved properly

[emolter]

https://github.com/spacetelescope/RegressionTests/actions/runs/18472624596 pointing to stdatamodels spacetelescope/stdatamodels#602

All changes are expected: S_REGION header keywords are added to TSO3 x1dints products.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.47%. Comparing base (38c180a) to head (2dc5920).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9927      +/-   ##
==========================================
+ Coverage   85.45%   85.47%   +0.01%     
==========================================
  Files         366      366              
  Lines       37845    37881      +36     
==========================================
+ Hits        32341    32377      +36     
  Misses       5504     5504              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[melanieclarke]

Looks good, thanks! Just a couple minor suggestions.

For the question about picking the first S_REGION - it looks to me like it might be technically possible to get an S_REGION that is not identical in the input calints files, since it is assigned from the WCS by exposure, in this function:

jwst/jwst/assign_wcs/util.py

Line 761 in bf7d548

def compute_footprint_spectral(model):

Combining multiple spectral targets in tso3 wouldn't make sense though, so I would think that any input S_REGION should be close enough for the purpose. I suggest we move forward with this solution and revise later if we turn up significant exceptions.

[melanieclarke]

I tested locally on a NIRSpec BOTS association with multiple segments and NRS1 and 2 detectors (jw01118-o005_20250917t232840_tso3_00001_asn.json). For this association, all the input S_REGIONS are the same. The output x1dints file has 6 extensions, one for each of 3 segments and 2 detectors. The S_REGION is recorded only in the first spectrum, and matches the S_REGION from all the input files.

I know the choice to record in the first only is consistent with the WFSS implementation, but it still seems a bit unintuitive to me -- it would be more natural to record it in either the primary HDU, or else in every EXTRACT_1D extension. Perhaps we should file a follow up ticket to add S_REGION to all the x1d/x1dints extensions?

Either way, I think this PR is fine as is, and we can leave any further S_REGION improvements for the future.

Can you please re-run regression tests after the stdatamodels PR gets merged, just in case?

[emolter]

Can do RE regtests.

I totally agree, it's not intuitive to me either. I don't recall exactly why the choice was made, besides that there's no SCI extension. But given that we're not directly calling the wcsinfo subschema, I don't see any issue with just storing it in the primary. To me, the primary header makes more sense because it's supposed to represent (at least for WFSS data) the total region over which sources were extracted. And plus then the same value wouldn't be stored hundreds of times.

But we can discuss on the ticket.

[emolter]

https://github.com/spacetelescope/RegressionTests/actions/runs/18761792709

these all look as expected and are ready for okify

[melanieclarke]

Thanks for getting this fixed!

[tapastro]

@meeseeksdev backport to release/1.20.x