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/handlers/image.go

@@ -110,13 +110,6 @@ func (s *Handlers) parseImageRequest(
 
 	if fit := query.Get("fit"); fit != "" {
 		req.FitMode = imgcache.FitMode(fit)
-
-		fitErr := imgcache.ValidateFitMode(req.FitMode)
-		if fitErr != nil {
-			s.respondError(w, "invalid fit mode: "+fit, http.StatusBadRequest)
-
-			return nil, false
-		}
 	}
 
 	// Default quality if not set
@@ -129,6 +122,18 @@ func (s *Handlers) parseImageRequest(
 		req.FitMode = imgcache.FitCover
 	}
 
+	// Enforce dimension and fit-mode bounds, shared with the encrypted-URL
+	// route. Dimensions are already bounded by the path parser above; this
+	// also rejects an unrecognized fit mode with 400 instead of letting it
+	// reach the processor as a 500.
+	err = imgcache.ValidateImageRequest(req)
+	if err != nil {
+		s.respondError(w, "invalid image request: "+err.Error(),
+			http.StatusBadRequest)
+
+		return nil, false
+	}
+
 	return req, true
 }