fix: preserve responsive WebP in Jimp fallback

[AnnoyingTechnology]

Closes #2640.

What this fixes

Publii currently falls back from Sharp to Jimp when the Sharp worker fails. With forceWebp enabled, Jimp writes the source format to fallbackDestinationPath, while the renderer still emits .webp responsive image URLs. This leaves generated and deployed sites with missing responsive images.

This PR makes the fallback preserve the requested image format:

• adds a lazily loaded WebAssembly WebP encoder/decoder for the Jimp path;
• writes real WebP data to destinationPath when WebP conversion is enabled;
• lets the Jimp engine process WebP source images as well;
• enables WebP conversion when Jimp is explicitly selected;
• removes the now-obsolete UI warnings that WebP requires Sharp.

Sharp remains the default and fast path. The WASM codec is loaded only when Jimp needs WebP support.

Why this does not change the Sharp worker

The reproduced Sharp crash is the documented Electron/Linux GLib symbol conflict, tracked in electron/electron#46323. The same Sharp 0.34.3 operation succeeds under standalone Node, but Publii does not bundle a separate Node runtime and cannot safely assume a compatible system Node exists. This change fixes the Publii-owned fallback contract independently of that upstream runtime issue.

Verification

• Added encode/decode coverage for the WebP helper.
• Added integration coverage proving that the Jimp path writes destinationPath.webp and does not write the PNG fallback.
• Verified a 300 px derivative from the affected JPEG is valid WebP and no JPEG fallback is created.
• Verified the codec under Publii's installed Electron 41.9.1 runtime.
• Verified dynamic loading and WASM file access from an ASAR archive.
• git diff --check and Node syntax checks pass.

Targeted tests:

2 passing

Full existing backend suite:

100 passing, 3 failing

The three failures are pre-existing feed-link.spec.js whitespace expectations and are unrelated to this change.