…:Directory`.

Escape the root path before interpolating into a regular expression,
preventing RegexpError when the root contains metacharacters and
avoiding path disclosure when regex silently mismatches.

If a wildcard has already been seen as an acceptable encoding,
ignore additional wildcards.

Other improvements while here:

* Only process up to 16 encodings.

* Improve efficiency of candidate sorting.

Add tests for:

* Lower but non-zero wildcard priority

* Multiple wildcards with different priorities

RFC 1341 specifies there should be a single boundary parameter.
Requests with multiple boundary parameters are unlikely to be
legitimate, and likely are attempts to exploit parsing differences
between rack and web application firewalls.

* Disallow whitespace between boundary and = when parsing multipart boundaries

Rack has historically not accepted these. To avoid security issues
when parsing multiple boundaries, check for boundary cases that may
have whitespace, but explicitly disallow the parsing if there is
whitespace.

Decode path once in applicable_rules before matching, fixing:
- URL-encoded paths bypassing :fonts, Array, and Regexp header rules.
- Path mutation across rules when String rule unescapes inside find_all.
- Array rule values interpolated into regexp without Regexp.escape.

`String#size` returns character count, not byte count. For responses
containing multi-byte UTF-8 characters, this produces an incorrect
`Content-Length` value, violating RFC 9110 Section 8.6.

Allow exceeding this limit by passing max_ranges keyword argument.

If the limit is exceeded, return nil, treating the request as not
requesting ranges. This seems better than returning [], which would
treat the request as requesting no ranges. We use [] when the total
size exceeds the size of the file, as such case is obviously a
problem. However, a request with more than the given number of
ranges is not obviously a problem.

Mention the substitution is case insensitive in the documentation,
since if the file system is case sensitive, this would be unexpected.

This is similar to the fix of CVE-2026-22860 for Rack::Directory.

Compare the declared `Content-Length` against a configurable maximum (`PARSER_BYTESIZE_LIMIT`) before any parsing begins.

If it exceeds the limit, raise an exception immediately.