fix(storage-resize-images): bump sharp to ^0.35.3

[IzaakGough]

What was broken: the storage-resize-images kit depends on sharp@^0.34.5. Everything below 0.35.0 inherits four libvips CVEs (CVE-2026-33327, -33328, -35590, -35591), reported by npm audit as GHSA-f88m-g3jw-g9cj and rated high. The extension already moved to ^0.35.3; the kit was created a week later with the older range and has not been updated since.

What changed: the dependency range and the lockfile. The lockfile diff is limited to sharp, its @img/* platform packages and the bundled libvips binaries, plus two new optional wasm targets that ship with 0.35.x.

Verification: npm ci and npm run build are clean. resize() across four size formats and convertType() across jpeg, png, webp, tiff, gif and avif, including the outputOptions and animated paths, return identical dimensions and formats on 0.34.5 and 0.35.3; only the encoded byte counts for tiff and avif differ, as expected from a libvips bump. The full Storage upload path was not exercised.

The one breaking change in the 0.35 line is the switch to named ESM exports. The kit already uses import sharp from "sharp", so nothing needed changing.

Follow-up, kept separate: the kit also carries mkdirp and uuid, which the extension removed in favour of Node built-ins.

[gemini-code-assist]

Code Review

This pull request renames the package to @firebase-function-kits/storage-resize-images, resets its version to 0.0.0, and upgrades the sharp dependency from ^0.34.5 to ^0.35.3. A critical issue was raised regarding the sharp upgrade, as version 0.35.x removes the default export in favor of named exports, which will cause compilation or runtime errors unless the imports in the codebase are updated.

[IzaakGough]

A fresh-eyes review caught a regression this bump introduces, now fixed in bea965a7.

resize() passed failOnError: false to the sharp constructor. sharp 0.35 removed that property and silently ignores unknown constructor keys, so failOn reverted to its default of warning. Images libvips can only partially decode were resized best-effort before and would have started failing, in the default configuration (SHARP_OPTIONS defaults to {}). The failure is caught in modifyImage, so the resize would just silently not happen and the original would be routed to the failed-images path.

Reproduced with a truncated JPEG, passing the exact options the kit passes:

sharp	failOnError: false	failOn: "none"
0.34.5	OK	OK
0.35.3	FAIL: VipsJpeg: premature end of JPEG image	OK

The fix is failOn: "none", the direct equivalent of the old spelling. Confirmed through the kit's own resize(): a truncated JPEG now succeeds in the default config, a healthy image is unaffected, and a user failOn set via SHARP_OPTIONS still overrides it, since it is spread after.

Worth noting separately: the extension carries the same dead failOnError at storage-resize-images/functions/src/resize-image.ts:60 and is already on ^0.35.3, so it is affected too. Not fixed here.