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

internal/imgcache/imgcache.go

@@ -59,6 +59,23 @@ func ValidateFitMode(fit FitMode) error {
 	}
 }
 
+// ValidateImageRequest checks that a request's dimensions are within
+// MaxDimension and its fit mode is recognized. Both the plain /v1/image/
+// route and the encrypted /v1/e/ route validate through this function so a
+// request from either source enforces identical bounds, regardless of how it
+// was constructed. A width or height of 0 means "original size" and is valid.
+func ValidateImageRequest(req *ImageRequest) error {
+	if req.Size.Width < 0 || req.Size.Height < 0 {
+		return ErrInvalidSize
+	}
+
+	if req.Size.Width > MaxDimension || req.Size.Height > MaxDimension {
+		return ErrDimensionTooLarge
+	}
+
+	return ValidateFitMode(req.FitMode)
+}
+
 // ImageRequest represents a request for a processed image
 type ImageRequest struct {
 	// SourceHost is the origin host (e.g., "cdn.example.com")