Bump imapengine from 1.25.4 to 1.25.6 and dependencies

libs/vendor/guzzlehttp/psr7/docs/uri-and-mime-helpers.md

@@ -32,6 +32,28 @@ userinfo.
 A URI that does not parse has no trustworthy authority boundary, so everything
 between any scheme and its last `@` is redacted as a safe-side fallback.
 
+## `GuzzleHttp\Psr7\Utils::redactUriForMessage`
+
+`public static function redactUriForMessage(UriInterface $uri): string`
+
+Formats a URI for automatic diagnostics.
+
+The whole userinfo component is replaced by "***", and the query and
+fragment are removed. The scheme, host, port, and path are preserved.
+The returned string is diagnostic-escaped and the formatter never
+throws.
+
+## `GuzzleHttp\Psr7\Utils::redactUriStringForMessage`
+
+`public static function redactUriStringForMessage(string $uri): string`
+
+Formats a raw URI for automatic diagnostics, including malformed input.
+
+The whole userinfo component is replaced by "***", and the query and
+fragment are removed. The scheme, host, port, and path are preserved
+where their boundaries can be determined safely. The returned string is
+diagnostic-escaped and the formatter never throws.
+
 ## `GuzzleHttp\Psr7\Utils::uriFor`
 
 `public static function uriFor(string|UriInterface $uri): UriInterface`

libs/vendor/guzzlehttp/psr7/docs/uri-helpers.md

@@ -102,6 +102,14 @@ IDNA is treated as a client concern. Consumers that need DNS IDNs must perform
 the conversion themselves, for example via Guzzle's `idn_conversion` request
 option.
 
+Validity here is a statement about URI syntax only. It does not imply that the
+host resolves or that a client will interpret it exactly as written. A PSR-7 URI
+object does not know which resolver or transport will consume it, so it cannot
+establish destination identity. Consumers that restrict the destination must
+enforce that policy at the client or transport boundary and ensure the
+connection uses an approved address; checking the spelling or a separate DNS
+lookup is insufficient.
+
 ### `GuzzleHttp\Psr7\Rfc3986::isValidPort`
 
 `public static function isValidPort(string $port): bool`
@@ -248,6 +256,10 @@ the current request URI.
 
 Converts the relative URI into a new URI that is resolved against the base URI.
 
+When the resolved path is a relative-path reference whose first segment contains
+a colon, which would be mistaken for a scheme name (RFC 3986 Section 4.2), it is
+prefixed with `./`, e.g. `./a:b`.
+
 ### `GuzzleHttp\Psr7\UriResolver::removeDotSegments`
 
 `public static function removeDotSegments(string $path): string`
@@ -313,6 +325,13 @@ means the URIs `/?#` and `/` are treated equivalent which is not necessarily
 true according to RFC 3986. But that difference is highly uncommon in reality.
 So this potential normalization is implied in PSR-7 as well.
 
+A path the URI cannot hold, such as a `//`-leading path without an authority or
+a relative-path reference whose first segment contains a colon, is prefixed with
+`/.` or `./` respectively instead of throwing, as `UriResolver::resolve()` does.
+The percent-encoding normalizations only do so where they rewrote the path. For
+example, decoding `a%41:` yields `./aA:`, since `aA:` would be an absolute URI
+with the scheme `aa`.
+
 The following normalizations are available:
 
 - `UriNormalizer::PRESERVING_NORMALIZATIONS`
@@ -369,7 +388,11 @@ The following normalizations are available:
     `file:///myfile`, and `file://localhost/myfile` are equivalent according to
     RFC 3986.
 
-    Example: `file://localhost/myfile` → `file:///myfile`
+    When removing the host leaves a URI without an authority whose path begins
+    with `//`, the path is serialized with a `/.` prefix.
+
+    Example: `file://localhost/myfile` → `file:///myfile`,
+    `file://localhost//x` → `file:///.//x`
 
 - `UriNormalizer::REMOVE_DEFAULT_PORT`