Root-caused the "hard images misread" behaviour: Gemma 4 (GEMMA4UV) is a
dynamic-resolution vision model that caps an image at max 280 tokens
(clip.cpp: set_limit_image_tokens(40, 280)). That low cap downscales images
hard; on dark / low-contrast / small-subject photos the encoder loses the
subject and the model confabulates ("collage / repeated text"). The author's
own comment notes the model "performs quite poor with small images".

The mtmd C API already exposes image_min_tokens / image_max_tokens and passes
them to clip, but our vendored binding didn't surface them. This:
* adds image_min_tokens / image_max_tokens to MtmdContextParams (+ both From
  impls), defaulting to -1 (= keep model metadata default),
* wires EULLM_IMAGE_MAX_TOKENS / EULLM_IMAGE_MIN_TOKENS env overrides in
  init_mtmd_optional so the budget can be raised without recompiling.

Lets us empirically test whether more resolution fixes the hard images.
Caveat: very high values can OOM/crash some projectors (cf. llama.cpp#21550);
raise in moderate steps (512, then 1024).

Second 0.6.1 pre-release. Over beta.1:
* expose EULLM_IMAGE_MAX_TOKENS / EULLM_IMAGE_MIN_TOKENS to raise Gemma 4's
  280-token image cap (the suspected cause of hard-image misreads),
* revert the per-request MtmdContext experiment (no effect on the failure).

WebP→PNG conversion, stream-error surfacing and web audio carried over.