[4.x] Do not write credentials into the caller's URI in the stream transport - #92

Summary of Changes

With the userauth/passwordauth options set, the stream transport called $uri->setUser() and $uri->setPass() on the Uri object it was given. After a request the caller's object stringified as http://user:secret@host/path, so the password ended up in whatever logged or reused that object, and in exception messages such as Could not connect to resource %s. A UriImmutable got no credentials at all, because the code only handled the mutable Uri.

The credentials are now sent as an Authorization: Basic … header, as the cURL and socket transports effectively do, and the URI object is left alone. If the request already carries an Authorization header it wins, as it did before (PHP's http wrapper does not add the URL's credentials when such a header is present).

The finding also suggested cloning the URI before modifying it. That would have kept the credentials in the URL used for the request and in exception messages, so the header was preferred.

Testing Instructions

Tests/Transport/StreamCredentialsTest.php (new, needs the stub):

• the stub receives the credentials and the caller's Uri still stringifies without them (before: http://username:secret@…);
• a UriImmutable gets the credentials too (before: none).

Documentation Changes Required

docs/classes/TransportInterface.md: the userauth/passwordauth row lists all transports and says how the stream transport sends them. #82 changes the next row of the same table, so whichever is merged second needs a trivial rebase.

🤖 Generated with Claude Code