fix: parse charset when Content-Type has whitespace after ';'

[jaideeppyne]

Fixes # .

split_content_type() failed to pick up the charset when the Content-Type header has a space after the ;, e.g. application/json; charset=utf-8. It matched parameters with startswith("charset=") on the raw semicolon-split parts, without trimming the optional whitespace that RFC 7231 allows. So the common spaced form returned encoding=None, and the request/response validators silently fell back to utf-8 and mis-decoded bodies sent in another charset.

Reproduction on current main:

'application/json;charset=utf-8'   -> ('application/json', 'utf-8')   # worked
'application/json; charset=utf-8'  -> ('application/json', None)      # bug (expected 'utf-8')
'text/html; charset=UTF-8'         -> ('text/html', None)             # bug

Changes proposed in this pull request:

• Strip optional whitespace around the media type and each parameter in split_content_type before matching the charset parameter.
• Add a regression test covering the no-parameter, unspaced-charset, spaced-charset, and charset-after-another-parameter cases.