placeholder=blur from Jahia thumbnails

[romain-pm]

Part of #734. A low-quality placeholder while the real image loads.

next/image ships placeholder: "blur" | "empty" | \data:image/...`withblurDataURL. Jahia already generates thumbnail renditions, and ?t=thumbnail` is the one resize a plain instance performs offline (#735) — so the LQIP source exists without any new infrastructure.

• placeholder="blur", backed by the smallest available thumbnail, applied as a background-image on the <img> the way Next does.
• blurDataURL for a caller-supplied data URI.
• Decide whether reading the thumbnail's bytes at render time is acceptable in the GraalJS server runtime, or whether this has to be a URL reference rather than an inlined data URI. That answer decides whether the feature is possible at all.

[romain-pm]

The blocking question is answered: reading thumbnail bytes at render time is possible. The engine builds its GraalJS context with allowHostClassLookup(s -> true) and HostAccess.ALL (GraalVMEngine.ContextPoolFactory), so Java.type("java.util.Base64") and a synchronous getBinary().getStream() are both reachable, and nothing here needs async I/O or a Node API.

What stops the inlined data URI is cost, not capability: a datastore read plus a base64 encode per image per render, and 7–20 KB of inline HTML each — where Next does it once at build time.

So #766 implements the URL-reference form: placeholder="blur" paints the smallest pre-generated thumbnail as a background-image, and blurDataURL takes a caller-supplied data URI or URL. Two limits, documented in the guide:

• the placeholder is not cleared once the image loads — the component is server-only, so there is no client code to clear it, and it stays behind a transparent PNG;
• the SVG-filter blur next/image uses cannot work from a URL (a data: URI SVG may not load external subresources), so the blur is the browser upscaling a 150px file.

Inlining stays open as a follow-up if a call site shows the extra request actually costs more than the render does.