Some web platform tests assume that an alpha of 1, when passed to the lightness channel of lab/lch, should result in a lightness value of 100:

https://github.com/web-platform-tests/wpt/blob/master/css/css-color/parsing/color-valid-relative-color.html#L420

It appears that the logic for this is that the [0, 1] range for alpha should be mapped onto the [0, 100] range for lightness. I see nothing in the spec stating this should be the case:
https://csswg.sesse.net/css-color-5/#relative-colors
https://csswg.sesse.net/css-color-5/#relative-Lab

In fact, this text seems to imply that numbers are not remapped/normalized:

Except as specified for individual color functions, (for example, HWB Whiteness and Blackness return <percentage>), the channel keywords return a <number>; if they were originally specified as a <percentage> or an <angle>, that <percentage> is resolved to a <number> and the <angle> is resolved to a <number> of degrees (which is the canonical unit) in the range [0, 360].

If color keywords inputs were to be mapped to their ranges, many tests are missing from wpt, for example:

• Passing lightness to other components.
• Normalizing the hue angle.
• 100% for a in lab maps to a raw value of 125, should a values then be normalized as if they are in the range [0, 125]?
• The above problem also exists for oklab, but with the range [0, 0.4]
• The interaction of math functions with any of the above.

Given that the spec is not explicit about this behavior and it is non-trivial, am I correct in assuming the aforementioned tests are incorrect?

web-platform-tests/wpt#41113