imaging.getPixels() does not return alpha channel for Grayscale and LAB color modes

[kayrockscreenprinting]

The imaging.getPixels() API returns 1 component for Grayscale images and 3 components for LAB images, even when the layer contains transparent pixels. According to the documentation, Grayscale should support 2 components (Gray + Alpha) and LAB should support 4 components (L + a + b + Alpha).
Documentation reference:
https://developer.adobe.com/photoshop/uxp/2022/ps_reference/media/imaging/#terminology-and-data-types
The docs state:

Grayscale: 1 component (gray) or 2 components (gray + alpha)
LAB: 3 components (L, a, b) or 4 components (L, a, b + alpha)

Current behavior:

const pixelData = await imaging.getPixels({ layerID: layer.id });
console.log(pixelData.imageData.components); // Returns 1 for Grayscale, even with transparency
console.log(pixelData.imageData.colorSpace); // "Grayscale"

Layer has visible transparent pixels, but components is 1, not 2. There is no way to determine which pixels are transparent from the returned buffer.
Expected behavior:
When a Grayscale layer contains transparency, getPixels() should return 2 components (gray + alpha). Similarly, LAB layers with transparency should return 4 components.
Workaround:
Currently developers must use batchPlay to select the transparency channel and then call imaging.getSelection() to obtain a separate transparency mask:

await batchPlay([{
    _obj: "set",
    _target: [{ _ref: "channel", _property: "selection" }],
    to: { _ref: [
        { _ref: "channel", _enum: "channel", _value: "transparencyEnum" },
        { _ref: "layer", _id: layer.id }
    ]}
}], {});
const selObj = await imaging.getSelection({ documentID: doc.id });

This workaround is cumbersome and requires aligning the selection bounds to the layer bounds manually.
Impact:

Plugins that process grayscale images cannot properly handle transparency
Converting to RGB just to access alpha is inefficient and may alter color data
Documentation promises functionality that doesn't work, causing developer confusion