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

Summary

This issue tracks the client-side enhancement that allows users to specify historyLength and other message send configuration options directly via the configuration parameter in BaseClient.send_message().

This complements the server-side fix in #497, which adds support for historyLength in the message/send endpoint.

Background

Currently, BaseClient.send_message builds the MessageSendConfiguration internally using values derived from ClientConfig.
However:

• ClientConfig does not include a history_length field, so the client cannot provide this value through configuration.
• In contrast, the get_task method already accepts historyLength through TaskQueryParams at the call site, which provides more explicit and flexible behavior.

This inconsistency prevents clients from controlling the number of task history entries returned by message/send flexibly.

Relation to Other Issues

• Related to / Complements: #497
  (server-side implementation of historyLength support)

Expected Outcome

After both #497 and this issue are resolved:

• Clients can specify historyLength per request when calling send_message.
• The server correctly trims the returned task history based on that parameter.
• Behavior is consistent with get_task, which already uses a call-site
  historyLength via TaskQueryParams.

Describe the solution you'd like

• Add configuration: Optional[MessageSendConfiguration] argument to BaseClient.send_message.
• When provided, merge the call-site configuration with ClientConfig defaults.
• Support partial overrides: e.g., if only history_length is provided, all other
  parameters still come from ClientConfig.
• Pass the merged configuration to the transport layer.
• Add tests to ensure the correct behavior in both streaming and non-streaming paths.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

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