fix(storage-resize-images): reject unsupported IMAGE_TYPE values

[Sanjays2402]

Fixes #3168.

Problem

An IMAGE_TYPE value that is not a supported image format was never validated. It reached the resize path, produced an unconverted file with a bogus extension (e.g. <name>_<size>.bogus with contentType: undefined, served as application/octet-stream), and the run reported success. This is reachable via an out-of-band value, for example a hand-edited .env file.

Changes

• storage-resize-images/functions/src/config.ts: validate IMAGE_TYPE against the keys of supportedImageContentTypeMap (plus "false" for keeping the original type) when the config is resolved. An unknown value now throws a descriptive error — Invalid IMAGE_TYPE value(s): bogus. Supported values are: jpg, jpeg, png, tif, tiff, webp, gif, avif, jfif, false. — instead of silently producing broken output. Empty entries are ignored, since that is what a deployed function receives when the multiSelect parameter has nothing selected (per the discussion in feat(storage-resize-images): reject unknown IMAGE_TYPE values at config resolve time #3124).
• storage-resize-images/extension.yaml: added validationRegex / validationErrorMessage to the IMAGE_TYPE param so out-of-band values are also rejected at install/reconfigure time.
• storage-resize-images/functions/__tests__/config.test.ts: new IMAGE_TYPE validation test block covering accepted values, unset param, empty (nothing selected), and rejected values including mixed lists.

Note: #3168 asks for the same change in the kit (kits/storage-resize-images), but no kits/ directory exists in this repository (checked on both next and main), so only the extension half can land here.

Test evidence

• npx jest __tests__/config.test.ts: 9/9 pass (4 pre-existing + 5 new); existing snapshot unchanged.
• Broader unit run (--testPathIgnorePatterns e2e integration vulnerability function.test): 54/54 tests pass. The only 2 failing suites (unit/modifyImage, unit/generateResizedImageHandler) fail identically on the pristine next branch — a pre-existing IMG_SIZES env issue unrelated to this change.
• npx tsc --noEmit: clean.
• Manual repro of the issue scenario against the compiled config: IMAGE_TYPE=bogus now throws Invalid IMAGE_TYPE value(s): bogus. ... at startup; jpeg,webp,false resolves to ["jpeg","webp","false"] unchanged.

[gemini-code-assist]

Code Review

This pull request adds validation for the IMAGE_TYPE parameter in the storage-resize-images extension. It introduces a validation regex and error message in extension.yaml, implements backend validation in config.ts to reject unsupported formats, and adds comprehensive unit tests. The reviewer pointed out that the validationErrorMessage in extension.yaml is missing several supported formats (such as jpg, tif, and jfif) that are allowed by the regex, and suggested updating it for completeness and consistency.

[gemini-code-assist]

The validationErrorMessage does not list all the image formats supported by the validationRegex (such as jpg, tif, and jfif). To prevent user confusion and ensure consistency with the backend validation error message in config.ts, please update the error message to list all supported formats.

    validationErrorMessage: >
      Invalid image type. Supported values are: jpg, jpeg, png, tif, tiff,
      webp, gif, avif, jfif, or "original" (false) to keep the original file type.

[Sanjays2402]

Good catch — fixed. The error message now lists all formats the regex and backend accept: jpg, jpeg, png, tif, tiff, webp, gif, avif, jfif, plus "original" (false). It matches the backend validation message in config.ts as well.