fix: use exact token matching and respect q=0 in matchAcceptEncoding

[amitmishra11]

Summary

The matchAcceptEncoding helper in middleware/compress.go used strings.Contains to test whether an encoding appears in the Accept-Encoding header. This caused two correctness bugs:

1. Substring false positives

strings.Contains("br", "b") returns true, so a client sending Accept-Encoding: br would be matched by the encoding "b". Similarly, "bgzip" incorrectly matched "gzip".

2. q=0 ignored

Per RFC 9110 section 12.5.3, a quality value of 0 means the encoding is not acceptable. The old code matched "gzip;q=0" as if gzip were acceptable, causing the middleware to compress with an encoding the client explicitly refused.

Changes

middleware/compress.go

Rewrote matchAcceptEncoding to:

• Split each header token on ";" to separate the encoding name from quality parameters
• Trim whitespace around both the token and the parameter
• Compare the encoding name with exact string equality (not substring)
• Reject the match when the quality parameter is q=0 (or equivalent 0.0, 0.00, 0.000)

middleware/compress_test.go

Added TestMatchAcceptEncoding with table-driven cases covering:

• Exact match
• Substring false positives ("br" vs "b", "bgzip" vs "gzip")
• q=0 rejection
• Non-zero quality values (q=1, q=0.5)
• Multiple accepted encodings
• Empty accepted list
• Whitespace trimming

Testing

$ go test ./...
ok  github.com/go-chi/chi/v5            3.5s
ok  github.com/go-chi/chi/v5/middleware 27.6s

Fixes #1069