fix: add pixel spacing extraction fallback to Imager Pixel Spacing tag

[julianlinaress]

Context

In some MG datasets, PixelSpacing (0028,0030) is missing but
ImagerPixelSpacing (0018,1164) is present (e.g., 0.1, 0.1). The loader
currently only checks 0028,0030, so imagePlaneModule.usingDefaultValues
becomes true, hasPixelSpacing is false, and measurement tools fall back
to px. This change adds a fallback to read 0018,1164 so pixel spacing is
recognized and measurements use real-world units.

No issue was filed; this was identified while debugging LengthTool units
showing px despite valid spacing in the DICOM header.

Changes & Results

• Add a fallback to read ImagerPixelSpacing (0018,1164) when
  PixelSpacing (0028,0030) is missing in WADO-URI metadata extraction.
• Before: hasPixelSpacing = false, measurements display in px.
• After: hasPixelSpacing = true, measurements use mm based on 0.1 spacing.
• No UI or public API changes.

Testing

Manual:

1. Load an MG study that lacks 0028,0030 but has 0018,1164 = [0.1, 0.1].
2. Inspect imagePlaneModule.pixelSpacing and verify it is [0.1, 0.1].
3. Use LengthTool and confirm the unit is mm (not px).
4. Load a study that already provides 0028,0030 and confirm behavior is unchanged.

Automated tests not added (metadata extraction path only).

Checklist

PR

• My Pull Request title is descriptive, accurate and follows the
  semantic-release format and guidelines.

Code

• My code has been well-documented (function documentation, inline comments,
  etc.).

Public Documentation Updates

• The documentation page has been updated as necessary for any public API
  additions or removals. (N/A, no public API changes)

Tested Environment

• "OS: Linux 6.6.87.2-microsoft-standard-WSL2"
• "Node version: 24.5.0"
• "Browser: N/A (not tested)"

[wayfarer3130]

This is an entire replacement for hte metadata extract information code that handles things consistently.
The problem is that you cannot just use imager pixel spacing - you have to set it up so that it displays a calibration warning that this is imager pixel spacing. That warning is legally required by the FDA when being used for a diagnostic context because the spacing isn't spacing in the body.

[julianlinaress]

Oh, ok. I did not see any warning in the viewer I used for comparison. Since there’s no existing pattern, how would you want this represented in Cornerstone’s data model? Should we add a calibration marker/flag for Imager Pixel Spacing usage, or should we avoid using that tag entirely?

[wayfarer3130]

See: https://viewer-dev.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.4792.2001.105216574054253895819671475627
It shows as "Proj", meaning projected. There is a full PR that fixes this, but it isn't quite ready for merge yet:
#2494
You could do just the minimal required changes, but I still think it will take a while.

What I'm hoping to do is split the changes out into @cornerstone/metadata and share them with the various versions so it works consistently for all data sources, and that we can release a version but not use it int he OHIF 3.12 release until we have time to fully test it.