Keep the multipart parameter name ASCII compatible. - #2513

Fixes #2510, following up on @jeremyevans' reply there.

tag_multipart_encoding applies a part's charset to the parameter name as well as to
the body. The query parser compares that name against ASCII literals (name.index('[', 1)),
so a charset that is not ASCII compatible — UTF-16LE, or a dummy encoding such as UTF-7
that REENCODE_DUMMY_ENCODINGS does not cover — makes parsing fail with
Rack::QueryParser::IncompatibleEncodingError. The name now falls back to UTF-8 in that
case; the body keeps the charset it was given.

The check sits at the end of handle_dummy_encoding because that is the one point every
multipart name passes, after ISO-2022-JP has been transcoded; putting it in
tag_multipart_encoding would mean duplicating knowledge of REENCODE_DUMMY_ENCODINGS
there. It re-tags rather than transcodes on purpose: name.encode(Encoding::UTF_8) raises
for a dummy encoding like UTF-7, and for a UTF-16LE name with an odd byte count.

UTF-8, Shift_JIS, ISO-2022-JP and unknown charsets are unaffected.

One existing test changes: spec_method_override.rb "writes error to RACK_ERRORS when
using incompatible multipart encoding" (added in #2416) asserts exactly this case as a
rejection, so it now asserts the opposite. Flagging it explicitly since it walks back part
of a change in the same unreleased cycle — happy to drop this PR if you would rather keep
those parts rejected.

The new fixture covers all three shapes in one body: a flat name, a nested nested[text]
name, and a dummy encoding. Both new tests fail without the parser change.

🤖 Generated with Claude Code