Expose development vs production mode to JavaScript

[romain-pm]

Part of #734. A module has no way to know whether it is running on a developer's instance or in production, so the library cannot warn about anything only a developer would want to hear.

The immediate need is #737: buildImageUrl knows when a resize hint will be silently ignored (default provider, no Media Optimization) — the single worst image trap — but can only report it, not surface it. Same shape as any other develop-time-only diagnostic the library might add later.

The engine already computes it: ViewRenderError.isDevelopmentMode() wraps SettingsBean.getInstance().isDevelopmentMode(). It just isn't on the server bridge (GraalVMEngine.java:284 assembles those helpers).

• Expose it, e.g. server.config.isDevelopmentMode(): boolean on ConfigHelper — or argue for a better home.
• Type it in globals.d.ts.
• Warn once per image whose candidates land on the inert query channel, naming the node and pointing at the images guide.

Warnings must be develop-only and must not repeat per render — production pays nothing, and a dev tailing logs should not drown.

[romain-pm]

Implemented on the #746 branch (commit 8d77711): server.config.isDevelopmentMode() on ConfigHelper, and getImageProps uses it to warn about the inert ?w= channel.

Two corrections to this issue's own text, found during implementation:

• ViewRenderError.isDevelopmentMode() does not exist on main — it is on an unmerged branch, so there was nothing to reuse and the three-line check is inlined in ConfigHelper. When that branch lands there will be two copies; the follow-up is to have one delegate to the other.
• No methodWhitelist entry was needed — .java-ts-bind/package.json already whitelists ConfigHelper.*, so the regenerated typings will carry the method. Until a Maven build runs, a marked-for-deletion declaration file bridges it (same pattern as the getProvider bridge).

One deliberate change from the plan: the warning fires once per engine lifetime, not once per image. What it reports is a property of the instance — if these parameters are ignored for one asset they are ignored for all — so a per-image warning would print the same sentence twenty times on a gallery page. It names one image as its example.

The Java change could not be compiled here (no Maven in the worktree); SettingsBean.getInstance() and isDevelopmentMode() were verified against jahia-impl with javap, and CI's build job is the real check.