fix(storage-resize-images): map the Off content-filter option to OFF

[cabljac]

Picking "Off (No filtering)" for the content filter breaks the kit completely: the select option stored "False", the deployed environment carried CONTENT_FILTER_LEVEL=False, and convertHarmBlockThreshold threw "Invalid HarmBlockThreshold: False" on every storage event. The fix maps the option to "OFF", which the resolver converts to a null threshold and content-filter.ts treats as filtering disabled. The dead CONTENT_FILTER_OPTIONS const, which recorded the intended values but was used nowhere, is deleted.

New tests in tests/config.test.ts read the CONTENT_FILTER_LEVEL param from declaredParams and pin the full option list, resolve every option through resolveResizeImagesConfig (OFF yields a null threshold), and pin that "False" is rejected. The option-list and resolve tests fail on the previous code. Full kit suite, tsc -b, and prettier are clean. Verified in unit tests only; no live deploy was run.

Fixes #3047

[gemini-code-assist]

Code Review

This pull request updates the CONTENT_FILTER_LEVEL configuration in the image resizing kit, changing the 'Off' option value from 'False' to 'OFF' and removing the unused CONTENT_FILTER_OPTIONS constant. It also adds tests to verify that configuration options resolve correctly. The review feedback highlights a backward compatibility issue where existing deployments using the retired 'False' value would crash upon upgrade, and suggests gracefully mapping 'False' to null to disable filtering instead of throwing an error.

[CorieW]

Test report — no problems found

Unit tests + typecheck — kits/storage-resize-images: 179 passed / 6 skipped (187), tsc -b --force clean. The typecheck matters here because the PR deletes the CONTENT_FILTER_OPTIONS const outright; nothing else referenced it.

Regression-proved by reverting src/config.ts to the base — both new cases go red:

× offers OFF and the three block thresholds
× every option resolves, and OFF disables filtering
Tests  2 failed | 12 passed (14)

Parity is exact. The extension's storage-resize-images/extension.yaml:370-371 maps the same label to OFF:

- param: CONTENT_FILTER_LEVEL
  options:
    - label: Off (No filtering)
      value: OFF

So the kit's "False" was a straight typo against the extension, not an intentional deviation — confirms the fix direction.

Also worth saying: reading the declared param back out of declaredParams and asserting the full select.options array is a better test than checking the one changed string. It pins the invariant the bug violated (every option the select offers must be a value the resolver accepts) rather than just the symptom.

Live deploy — repacked the kit into a local functions-kit project and deployed all three resize instances to a real project:

3 x "Successful create operation."
+  Deploy complete!

This is a real exercise of the fixed path rather than a formality — the deployed instance configs are CONTENT_FILTER_LEVEL=OFF (x2) and BLOCK_ONLY_HIGH (x1), so deploy-time resolution ran against the corrected OFF value on two of the three.

Not verified: no image uploaded to confirm filtering is actually disabled at runtime. Application Default Credentials on this machine need reauth (invalid_grant / invalid_rapt), so I could not write to the bucket to trigger generateResizedImage.

No problems found.

[IzaakGough]

lgtm