Library exports a server Image component

[romain-pm]

Part of #734. Decided: the library exports the component. The "keep the component tier in userland" position does not survive contact with the code — the library already exports Island, Render, RenderChild, Area, AddResources, AddContentButtons, and a component emitting a bare <img> with no class is exactly as style-free as those. Astro ships both tiers (<Image> + headless getImage()).

<Image node={imageNode} alt={t("alt.estate", { estate: title })}
       layout="constrained" width={400} className={classes.estateImage} priority />

• Server component over getImageProps (Library image primitive: buildImageUrl + getImageProps #735): renders <img>, no styling, no wrapper element.
• Owns the loading policy every module currently reinvents or omits: loading="lazy" only when both intrinsic dimensions are known (lazy without reserved space causes CLS), priority → loading="eager" + fetchpriority="high".
• fallback prop: module static asset rendered when node is missing.
• Server-only (needs server context for the cache dependency) — state it in the name or the JSDoc, and fail with a clear message if used in a client component.
• Naming: Image collides with design-system Image at import sites in real modules. Decide Image vs JcrImage/ContentImage.

Out of scope: <Picture> (art direction, format switching) — a second component, later.

[romain-pm]

Decided: JImage. Image would collide with the design-system Image most modules already have (luxe is exactly that case), forcing an alias at every import site; the J prefix follows JCRNodeWrapper and reads as "the Jahia one". Implemented in #746.