[Feat]: Add missing constructor overloads to `A2ACardResolver`

[CokeLee777]

Is your feature request related to a problem? Please describe.

When using A2ACardResolver with the auto-selected HTTP client (A2AHttpClientFactory), there is currently no way to specify a custom agentCardPath or authHeaders without also manually providing a custom httpClient. This forces users to instantiate an A2AHttpClient themselves just to pass it in, which defeats the purpose of A2AHttpClientFactory.

For example, if I want to point to a non-standard agent card path like /custom/agent-card.json while still using the default HTTP client, none of the existing overloads support this:

• (baseUrl) ❌
• (baseUrl, tenant) ❌
• (httpClient, baseUrl, tenant) — requires manual httpClient instantiation
• (httpClient, baseUrl, tenant, agentCardPath) — requires manual httpClient instantiation
• (httpClient, baseUrl, tenant, agentCardPath, authHeaders) — requires manual httpClient instantiation

Describe the solution you'd like

Add the following two constructor overloads that use A2AHttpClientFactory.create() internally, consistent with the existing (baseUrl) and (baseUrl, tenant) overloads:

public A2ACardResolver(String baseUrl, @Nullable String tenant, @Nullable String agentCardPath) throws A2AClientError

public A2ACardResolver(String baseUrl, @Nullable String tenant, @Nullable String agentCardPath, @Nullable Map<String, String> authHeaders) throws A2AClientError

Both would simply delegate to the full 5-parameter constructor using A2AHttpClientFactory.create(), keeping the implementation minimal and consistent with the existing pattern.

Describe alternatives you've considered

A Builder pattern (e.g. A2ACardResolver.builder().baseUrl(...).agentCardPath(...).build()) would solve this more generally and avoid combinatorial explosion of overloads in the future. However, this is a larger change and may not align with the current design philosophy of the project. Happy to go with whatever direction the maintainers prefer.

Additional context

The two proposed overloads fill the only meaningful gap in the current overload matrix without introducing any breaking changes. Existing constructors remain fully intact.

Happy to submit a PR if this direction sounds good!

Code of Conduct

• I agree to follow this project's Code of Conduct