### Summary
When property-file/Map-based `ConnectionFactory` setup fails while parsing the `uri` key, the library wraps the underlying exception with the raw connection string — including the plaintext username and password — baked verbatim into the new exception's message.

### Details
`ConnectionFactoryConfigurator.load(ConnectionFactory, Map<String,String>, String)` (`src/main/java/com/rabbitmq/client/ConnectionFactoryConfigurator.java`, lines 142-155):

String uri = properties.get(prefix + "uri");
if (uri != null) {
try {
cf.setUri(uri);
} catch (URISyntaxException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
} catch (NoSuchAlgorithmException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
} catch (KeyManagementException e) {
throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e);
}
}

`uri` is the full AMQP URI — `amqp(s)://username:password@host:port/vhost` — concatenated verbatim into the exception message on any of the three catch branches. No masking/redaction exists anywhere in this class or in `ConnectionFactory.setUri()`. This is the library's documented Spring-Boot/ops-config entry point (`ConnectionFactory.load(...)`, available since 4.4.0), not obscure internal code.

RabbitMQ's own AMQP URI spec (rabbitmq.com/docs/uri-spec) explicitly warns the password "should avoid leaking... the full URI should not appear in exception messages or log records." A sibling method twenty lines away (`ConnectionFactory.setUri(URI)`) already avoids this exact mistake for a different malformed-URI case — this path wasn't caught by that same care.

Note: `KeyManagementException` is declared in the throws clause but not actually reachable via the current `setUri(String)` → `setUri(URI)` call chain — the two real, reachable leak surfaces are the `URISyntaxException` branch (trivial, deterministic, scheme-independent) and the `NoSuchAlgorithmException` branch (real but narrower — `amqps://` only, requires a restricted/FIPS-style default TLS provider).

### PoC
Map<String, String> props = new HashMap<>();
props.put("uri", "amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod");
ConnectionFactory cf = new ConnectionFactory();
ConnectionFactoryConfigurator.load(cf, props, "");

Throws:

java.lang.IllegalArgumentException: Error while setting AMQP URI: amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod

A password containing a space is entirely ordinary under common corporate password policies, and `java.net.URI` rejects such input outright — this isn't a contrived edge case.

### Impact
Default Spring Boot startup-failure logging, an APM/error tracker, a CI job log, or an engineer pasting a stack trace into an internal or public ticket now holds the plaintext broker password, in a system typically far less access-controlled than wherever the credential is normally stored. Note the underlying `URISyntaxException` also carries the same string in its own message, chained as the cause of RabbitMQ's `IllegalArgumentException` — so removing RabbitMQ's own `+ uri` concatenation alone would not fully close this; the raw secret-bearing string also shouldn't be handed to `new URI()` for error-reporting purposes at all.

Suggested fix: don't include the raw `uri` string in the wrapped exception's message — redact the userinfo component (or omit the URI entirely) before including it in any exception text.