Package-level declarations

Five behaviours here are decisions rather than defaults, and each is pinned by a test:

• A problem document is always labelled application/problem+json, even when it was matched under application/json. RFC 9457 §3 permits the override, and echoing back application/json would strip the only wire-level marker saying the body is a problem document.

• instance is filled from request.path(), never request.uri — the query string is left out because problem documents get logged on both ends and query strings carry tokens often enough that echoing them back by default is the wrong trade. Set instance explicitly to include it.

• The catch-all handler rethrows CancellationException unless the status map claims it. A cancellation means the client is gone; answering it writes a document to a dead socket and logs a stack trace per dropped connection. TimeoutCancellationException still becomes a 504.

• A thrown ProblemException is answered with the document it carries, via an entry seeded into the catalog — so map<ProblemException> replaces it like any other. Its cause, when present, is logged server-side (error for a 5xx, debug otherwise) because StatusPages logs nothing it handles and the cause would otherwise be dropped silently.

• customize runs once, after whichever of map, onUnmapped or forStatusCode produced the problem, rather than being folded into each of those. Enrichment that belongs on every document — a trace id read off the ApplicationCall, say — would otherwise have to be repeated in every mapping instead of registered once. Registration is additive, unlike onUnmapped: each call adds a step and steps run in registration order, so two unrelated concerns — a trace id and a redaction pass, say — cannot silently drop one another.