Server hardening: no pixel-count cap on secondary allocations + no cooperative cancellation

Production-readiness audit. zenquant is solid on crash-safety (`#![forbid(unsafe_code)]` + `#![no_std]`, typed thiserror errors, a prior 2026-05-06 security audit), but two server-deployment gaps:

**1. No pixel-count ceiling on the secondary full-image allocations.** Quantize sizes several full-image scratch buffers directly from the input dims with no cap: `simd.rs:41 batch_srgb_to_oklab_vec` `vec![[0f32;3]; pixels.len()]` (12 B/px OKLab), the masking-weight `vec![1.0f32; pixels.len()]` (4 B/px) at lib.rs:821/1079/1392/1541/1684/1858, `histogram.rs:205-206` `Vec::with_capacity(pixels.len())` ×2, `masking.rs:75/177/126`. The caller's input buffer is already allocated, but a huge input drives 12-16 B/px of extra allocation. Fix (additive): reject `width*height` beyond a default ceiling in `validate_inputs`, and/or expose `QuantizeConfig::with_max_pixels(usize)` so servers can tune it.

**2. No cooperative cancellation.** The k-means refine (`median_cut.rs:191`) and Viterbi (`joint.rs`) loops run to completion with no `Stop` check — a server can't abort a slow quantize. Fix (non-breaking, additive): add `*_with_stop` entry points taking `enough::Stop` (default `Unstoppable`) and `stop.check()?` at the top of each refine iteration / Viterbi row.