Make Header-based auth compatible with http-auth protected (staging) sites

Problem/Motivation

When using the Header authorization plugin with Entity Share, HTTP basic authentication credentials embedded in the remote URL (e.g., https://username:password@example.com) are not properly extracted and used by the HTTP client.

This creates issues when remote sites are protected by HTTP basic authentication (such as staging environments protected by .htaccess), because even though the credentials are included in the URL configuration, the resulting HTTP requests fail with 401 Unauthorized errors.

The Header plugin currently uses the full URL (including any embedded credentials) as the base_uri for Guzzle, but Guzzle requires basic auth credentials to be passed separately via the auth option to work correctly.

Steps to reproduce

1. Set up a remote Drupal site protected with HTTP basic authentication (e.g., via .htaccess with username/password)
2. Configure an Entity Share remote with a URL that includes basic auth credentials: https://username:password@example.com:port
3. Configure the remote to use the Header authorization plugin (e.g., for API key authentication)
4. Navigate to the Entity Share pull interface and try to open a channel
5. Observe a 401 Unauthorized error when attempting to fetch content from the JSON:API endpoints

Proposed resolution

Modify the Header authorization plugin's getClient() and getJsonApiClient() methods to:

1. Parse the URL to extract any embedded HTTP basic auth credentials (username and password)
2. If credentials are found, pass them to Guzzle via the auth option
3. Remove the credentials from the URL before setting it as base_uri

This approach allows the Header plugin to support both custom header-based authorization (like API keys) and HTTP basic authentication simultaneously, which is a common requirement for staging/production environments.

Remaining tasks

• Review the patch
• Test the changes with a site protected by HTTP basic authentication
• Commit the fix

User interface changes

None.

API changes

None. This is an internal implementation change that maintains backward compatibility.

Data model changes

None.