Spec differentiates between ImageDecoder initialization with unsupported non-image MIME type and an unsupported image MIME type

There is a WPT that checks for a NotSupportedError promise rejection when the MIME type "junk/type"
https://github.com/web-platform-tests/wpt/blob/53a1437dcfc754a3dc8ffe0bd34f9a6524e49fcf/webcodecs/image-decoder.https.any.js#L163

This conflicts with a strict reading of the spec:

From https://w3c.github.io/webcodecs/#imagedecoder-constructor:
"If init is not valid ImageDecoderInit, throw a TypeError."

From https://w3c.github.io/webcodecs/#valid-imagedecoderinit:
"1. If type is not a valid image MIME type, return false."

From https://w3c.github.io/webcodecs/#valid-image-mime-type:
"A valid image MIME type is a string that is a valid MIME type string and for which the type, per Section 8.3.1 of [RFC9110], is image."

From https://w3c.github.io/webcodecs/#configure-the-image-decoder
"1. Let supported be the result of running the Check Type Support algorithm with init.type."
"2. If supported is false, run the Close ImageDecoder algorithm with a NotSupportedError DOMException and return "processed"."

If we put all this together, my reading of it says that if the MIME type supplied is anything besides "image/XXX", we should throw a TypeError in the ImageDecoder constructor. If we don't support XXX, then we should reject the ImageDecoder [[completed promise]] and ImageTrackList [[ready promise]] with NotSupportedError.

Is this what we want? I don't have any strong feelings either way, just want to understand if the test is wrong, or if this is an inconsistency in the spec that we want to correct.

Read the ImageDecoder constructor, valid ImageDecoderInit, valid image MIME type, and Configure the ImageDecoder sections linked in the issue. Compare their stated errors with the WPT at image-decoder.https.any.js line 163. Done means reaching agreement on whether the specification or test needs correction and documenting the resolved behavior.