v0.123.1

v0.123.1 - Keep credentials out of a failed fetch's message

A Media fetch that failed put the FULL url into the exception message, and an
exception message is logged and shipped to an error tracker as a matter of
course. A url carries credentials often enough that it belongs in neither:
userinfo holds them outright (https://user:pass@host/…), and a presigned
object-storage url puts a bearer-equivalent token in the query string.

Both messages — the empty body and the undeterminable mime type — now carry
scheme, host, port and path, which say WHICH fetch failed and nothing more. A
query string that was present is marked ?[redacted] rather than dropped
silently: "there was one, and it is not shown" is a different fact from "there
was none", and the difference matters when reading the failure.

https://alice:hunter2@files.example/a.pdf?token=SECRET
  -> https://files.example/a.pdf?[redacted]

Reported as #45 out of the v0.119.0 release audit. The vulnerable message has
been live since v0.106.0.

A PATCH, deliberately: ^0.123.0 resolves it, so an application already on
0.123 picks the fix up without changing a constraint.

BEHAVIOUR NOTE: the text of those two exception messages has changed. Nothing
else has — no API change, no dependency change. An application matching on
either string will need updating.

Audited before publishing: 2181 tests, phpstan clean, zero open Dependabot and
code-scanning alerts, redaction verified empirically against userinfo, presigned
and unparseable urls rather than read from the diff.