Package-level declarations

Two behaviors here are decisions, not defaults, and each is pinned by a test:

• There is no lenient mode. problemXml() takes no parameters, and plain application/xml never matches. The JSON side offers acceptPlainJson because tooling overwhelmingly labels everything application/json; XML has no equivalent convention, and an application's own XML dialect is not this library's media type to claim. With only one way in, there is also only one failure rule: a body labeled application/problem+xml that fails to decode propagates as SerializationException rather than falling back to Ktor's own exception. That covers both of the reader's refusals — a malformed document, and a well-formed one rooted at something other than <problem xmlns="urn:ietf:rfc:7807">.

• The transport's charset wins. The body is read with the charset the response declares, falling back to UTF-8; a document's own encoding pseudo-attribute is never consulted, since the bytes are already text by the time the codec sees them. RFC 7303 makes the transport authoritative for +xml media types, so this is the order the specification asks for — and it matches how the JSON half reads its bodies.