A response with Content-Type: text/plain; format=flowed; charset=ISO-8859-1 is decoded using UTF-8. Response.charset() only examines the first parameter after the media type, so the default decoder turns Latin-1 bytes for café into caf�.

Expected: recognize charset at any parameter position, preserving case-insensitive parameter names and quoted charset values. Text resembling charset inside a quoted value of another parameter must not be treated as a parameter. Missing or unsupported charsets retain the current UTF-8 fallback. HTTP parameter grammar: https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.6

Reproduced on current master with ResponseTest and DefaultDecoderTest: 26 tests, seven failures, no errors or skips. Main sources compile with JDK 8 and tests run with actual JDK 25 using the dev profile. The decoder regressions exercise the actual non-UTF-8 byte input, not only the charset accessor.

I will fix parameter scanning in Response and add these regressions. This is separate from outgoing FormEncoder handling in #3611 and the streaming work in #3551. No new dependency or public API.

_{Reproduction and report prepared and posted by an AI assistant for @hutiefang76.}