Add JPEG XL support, loaded on demand - #77584

Add client-side JPEG XL support without growing the vips worker
bundle. The 3 MB vips-jxl.wasm module is split into its own
@wordpress/vips/jxl-wasm script module that is only fetched the
first time a JXL image is processed.

How it works:
- packages/vips/src/jxl-wasm.ts is a tiny new script module whose
  only job is to export the base64 data URL for vips-jxl.wasm.
- @wordpress/vips/jxl-wasm is registered as a new wpScriptModuleExports
  entry so the build emits build/modules/vips/jxl-wasm.min.js (~3 MB)
  as a separately loadable module.
- vips-worker.ts adds vipsEnsureJxlSupport(), which on first call
  dynamic-imports '@wordpress/vips/jxl-wasm' to get the data URL,
  then RPC-passes it to the worker via setJxlWasmUrl().
- The worker (packages/vips/src/index.ts) stores the URL, adds
  vips-jxl.wasm to dynamicLibraries on the next getVips() call, and
  returns the URL from locateFile(). If vips was already initialized
  without JXL, the existing instance is discarded so the reinit picks
  up JXL support.
- packages/upload-media calls vipsEnsureJxlSupport() from prepareItem
  whenever the input or output type is image/jxl. image/jxl is added
  to CLIENT_SIDE_SUPPORTED_MIME_TYPES and 'jxl' to VALID_IMAGE_FORMATS
  and the ImageFormat type. The vipsConvertImageFormat wrapper MIME
  union is widened accordingly.
- JXL encoding uses effort=3 (libvips default 7 is too slow for
  interactive use).

Size impact:
- worker.min.js: unchanged (~13.1 MB, same as trunk).
- jxl-wasm.min.js: new separate module (~3.0 MB), fetched only when
  a JXL image is encountered.

Alternative to #77570, which bundles vips-jxl.wasm directly into the
worker (+3 MB on every editor page load). Opened so the size bot can
compare.

Refs #76981.

Resolve conflict in packages/upload-media/src/store/private-actions.ts:
trunk moved image format transcoding from client-side prepareItem to
server-driven thumbnail generation. Adopt the new pipeline and keep
the JXL WASM lazy-load, but trigger it in two places: prepareItem for
JXL input files, and transcodeImageItem for server-requested JXL
output.

JXL is not broadly web-compatible: most browsers (including Chrome) cannot
display it and the server cannot read it (GD/Imagick have no JXL decoder, and
fileinfo reports it as image/x-jxl). Uploading JXL as-is was rejected outright
— by the editor's allowed-MIME check and by core's wp_check_filetype_and_ext()
— and even when allowed produced an undisplayable attachment with no
dimensions or sub-sizes.

Decode JXL to JPEG client-side with vips (the JXL WASM module is already
lazy-loaded on demand) and upload the JPEG, mirroring how HEIC is handled. The
original .jxl is preserved as a companion file in $metadata['original'] so no
data is lost. The editor and front end now use the portable JPEG, with real
dimensions and the full set of sub-sizes.

- Register image/jxl as an allowed upload MIME type, and restore the type
  during validation via a magic-byte-checked wp_check_filetype_and_ext filter
  so the sideloaded original passes despite the image/x-jxl finfo mismatch.
- Add original-jxl sideload handling to the REST controller, skipping the
  dimension read since JXL cannot be measured server-side.
- Generalize the HEIC companion delete hook to clean up JXL originals too.
- Add an e2e test and JXL asset covering the conversion and companion.

# Conflicts:
#	packages/upload-media/src/store/private-actions.ts

# Conflicts:
#	packages/vips/CHANGELOG.md
#	packages/vips/README.md

Guard the contract that high-bit-depth (>8-bit) and gain-map JXL uploads
flatten to 8-bit JPEG sub-sizes while the full-fidelity original is
preserved byte-for-byte as the .jxl companion file.

Add two 200x150 fixtures (a genuine 16-bit JXL and an 8-bit JXL carrying
an ISO 21496-1 jhgm gain-map box) plus a self-contained generator
script. Both decode in wasm-vips to a JPEG derivative; the tests assert
the JPEG main + sub-size and verify the stored original is identical to
the upload, proving the bit depth and gain map survive in the original.

Resolve conflict in packages/vips/src/index.ts with trunk's #79188, which
switched inlined WASM from base64 data URLs to a Uint8Array wrapped in a
Blob URL on demand (getWasmUrl helper).

Align the JXL lazy-load path with the new scheme: the vips-jxl.wasm module
now resolves to a Uint8Array, so pass those bytes across the worker RPC and
wrap them in a Blob URL inside the worker, exactly like the HEIF library.
Rename setJxlWasmUrl -> setJxlWasm (and vipsSetJxlWasmUrl -> vipsSetJxlWasm)
since the value is bytes, not a URL, updating the worker wiring, README, and
CHANGELOG to match.

…inal

The JXL source-format companion (the preserved `.jxl`) is stored under the
`source_image` attachment-metadata key (`META_KEY_SOURCE_IMAGE`), the same
key the HEIC original uses, not a bare `original` key. Two stale references
still pointed at `original`:

- A comment in `private-actions.ts` and the e2e test prose claimed the
  `.jxl` is stored under `$metadata['original']`.
- The JXL e2e assertions read `media_details.original`, a field that is
  never written, so they returned `undefined` instead of exercising the
  preserved companion.

Point all of them at `source_image`, which the controller actually writes
and which `media_details` exposes (the raw attachment metadata). The bare
`original` key is not used anywhere; the scaled/full passthrough uses
`original_image` and the source-format companion uses `source_image`.

# Conflicts:
#	lib/media/class-gutenberg-rest-attachments-controller.php
#	packages/upload-media/src/store/private-actions.ts
#	packages/upload-media/src/store/types.ts

# Conflicts:
#	lib/media/class-gutenberg-rest-attachments-controller.php
#	packages/upload-media/CHANGELOG.md
#	packages/upload-media/src/store/utils/index.ts

Six defects found reviewing the JXL feature, each with a regression test:

- prepareItem left `generate_sub_sizes` at its server-side default of true
  for JXL, so create_item built every sub-size itself and the client
  sideloaded none - silently reverting JXL uploads to server-side
  processing.
- Detection keyed off `File.type` alone. Systems with no .jxl MIME mapping
  report an empty type, so the file was uploaded as a raw .jxl the server
  cannot read - which the new upload_mimes filter now lets through.
- The decode failure used a bare 'JXL_DECODE_ERROR' string, absent from
  the ErrorCode enum and from getErrorMessage()'s table, so an
  unrecoverable failure surfaced as "Upload failed / Please try again".
  The message was also untranslated.
- getVips() recorded "initialized with JXL" before the init resolved. A
  rejected init then left a permanently rejected vipsPromise that the
  reset guard could no longer clear, failing every later operation in the
  worker - including unrelated JPEG work.
- getVips() discarded a live vips instance without shutting it down,
  stranding its WASM heap for the lifetime of the worker.
- setJxlWasm() took a Uint8Array, which comctx does not recognise as
  transferable: it walked the ~3 MB array key by key on the calling
  thread and copied rather than transferred it. It now takes an
  ArrayBuffer.

vipsEnsureJxlSupport() also no longer caches a failed download, and
re-sends the bytes when it sees a replaced worker, so a recycle between
prepareItem's ensure call and its conversion cannot strand a JXL on a
worker that lacks the library.