fix: validate dimensions and fit mode on encrypted URLs (closes #62)

The encrypted /v1/e/ route built its image request straight from the
decrypted payload, so a token could request an over-limit dimension
(reaching libvips and exhausting memory) or an unknown fit mode
(surfacing as a 500 from the processor). The token generator discarded
every strconv.Atoi error, silently turning non-numeric width, height,
quality, or ttl into 0 and applying no upper bound on dimensions.

Add a shared ValidateImageRequest in internal/imgcache enforcing the
MaxDimension bound and ValidateFitMode, and apply it on both the plain
image route and the encrypted route so both reject an over-limit size or
an unrecognized fit mode with 400. The generator now parses each numeric
field explicitly and returns 400 naming the field for non-numeric or
out-of-range input, with width and height bounds-checked so an unusable
token cannot be minted.

Model: opus-4-8

TODO.md

@@ -29,6 +29,17 @@ P1: implement blocked networks configuration to extend SSRF protection
 
 # Completed Steps
 
+- 2026-09-21 validate dimensions and fit mode on the encrypted-URL
+  route and the token generator (closes #62): added a shared
+  `ValidateImageRequest` in `internal/imgcache` enforcing the
+  `MaxDimension` bound and `ValidateFitMode`, applied by both the
+  `/v1/image/` and `/v1/e/` routes, so an over-limit size or an unknown
+  fit mode is a 400 rather than an out-of-memory or a 500 from the
+  processor; the URL generator now checks every numeric form field and
+  rejects a non-numeric or out-of-range `width`, `height`, `quality`,
+  or `ttl` with a 400 naming the field instead of coercing it to `0`,
+  and `width`/`height` are bounds-checked so an unusable token cannot be
+  minted
 - 2026-09-21 http.Server hardening (closes #92): added
   `HTTPReadHeaderTimeout` (10s, bounds the slowloris header dribble) and
   `HTTPIdleTimeout` (120s, bounds keep-alive reuse) alongside the