feat(storage-resize-images): reject unknown IMAGE_TYPE values at config resolve time

[cabljac]

resolveResizeImagesConfig (kits/storage-resize-images/src/export-config.ts:186) does toArray(config.imageTypes) ?? [DEFAULT_IMAGE_TYPE] with no validation. A stale .env from before #3064 carries IMAGE_TYPE=["False"], and that value does not fail the resize: resize-image.ts:103 treats it as a format because "False" !== "false", SUPPORTED_IMAGE_CONTENT_TYPE_MAP["False"] is undefined, the output is written as <name>_<size>.False with contentType: undefined (served as application/octet-stream), and the run reports success. Reproduced against the kit's bucket stub.

The extension has the same gap (functions/src/config.ts:85) but its YAML never stored False, so this is stricter than parity, hence a follow-up rather than part of #3064.

Proposed fix: add validateImageTypes() beside validateAbsolutePathList in export-config.ts, accepting "false" plus every key of SUPPORTED_IMAGE_CONTENT_TYPE_MAP (src/global.ts:29-39, so jpg/tif/jfif stay legal for library consumers) and throwing Invalid image type: <value> otherwise. Do not throw in convertType: tests/convert-image.test.ts:91-101 pins pass-through for unsupported formats such as raw, matching the extension's util.ts:247. Tests: reject ["False"], accept every map key, and route the existing multiSelect audit in tests/config.test.ts through resolveResizeImagesConfig. README differences section should note the kit rejects unknown imageTypes values where the extension passed them through.

Raised in #3064 review by @IzaakGough.

[IzaakGough]

One thing worth settling before this gets implemented: whether validateImageTypes throws or falls back to DEFAULT_IMAGE_TYPE.

#3002 just changed configFromEnv to degrade instead of crashing on a partial env, including passing the raw IMAGE_TYPE text through when it is not a JSON list. Throwing here brings a cold-start crash back for some of the values that fallback produces. IMAGE_TYPE=[] resolves to ["[]"] today and fails per upload inside sharp; with this guard it would throw at resolve time instead. Both are defensible, they just point in opposite directions, so it seems better to pick one on purpose than to find it in review.

Worth adding to the test list too: [""], which is what a deployed function receives when the multiSelect has nothing selected. The proposed allowlist rejects it the same way it rejects ["False"].

On the stale .env, the two write paths spell the value differently. In firebase-tools 15.29.0, writeResolvedParams writes ParamValue.toString() into .env, which for a list is the comma-joined raw value, so .env carries IMAGE_TYPE=False, while the deployed environment gets toSDK(), which is JSON.stringify(asList()), so IMAGE_TYPE=["False"]. Both land on ["False"] in config once #3002's raw fallback applies, so the conclusion holds either way.

The resolved values above come from running them through the kit's configFromEnv and resolveResizeImagesConfig. The firebase-tools serialization is from reading the installed 15.29.0 source, not from a deploy.