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/imageenc.go

@@ -50,6 +50,19 @@ func (s *Handlers) HandleImageEnc() http.HandlerFunc {
 		// Convert payload to ImageRequest
 		req := payload.ToImageRequest()
 
+		// Apply the same dimension and fit-mode bounds as the plain image
+		// route: a sealed payload is trusted for its origin, not for staying
+		// within limits, so an over-limit size or unknown fit mode is a 400
+		// here rather than an out-of-memory or a 500 from the processor.
+		err = imgcache.ValidateImageRequest(req)
+		if err != nil {
+			s.log.Debug("encrypted URL failed validation", "error", err)
+			s.respondError(w, "invalid encrypted URL: "+err.Error(),
+				http.StatusBadRequest)
+
+			return
+		}
+
 		// Log the request
 		s.log.Debug("encrypted image request",
 			"host", req.SourceHost,