[Bug]: Spec contradiction for async behavior

### What happened?

There is a normative contradiction in the specification regarding whether a remote agent can return an in-progress Task when a client requests blocking execution (return_immediately: false or unset).

Section 3.2.2 ([SendMessageConfiguration](https://a2a-protocol.org/latest/specification/#322-sendmessageconfiguration)) states the blocking behavior as:

> Blocking (return_immediately: false or unset): The operation MUST wait until the task reaches a terminal state (TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_REJECTED) or an interrupted state (TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED) before returning.

Section 3.1.1 ([Send Message](https://a2a-protocol.org/latest/specification/#311-send-message)) states agent behavior as:

> The agent MAY create a new Task to process the provided message asynchronously or MAY return a direct Message response for simple interactions. The operation MUST return immediately with either task information or response message. Task processing MAY continue asynchronously after the response when a Task is returned.

The `MUST wait` in Section 3.2.2 strictly implies that a server cannot return early with an in-progress task state (e.g., TASK_STATE_WORKING or TASK_STATE_SUBMITTED) to avoid HTTP gateway timeouts performing LROs depriving the server's control over connection management.

Proposal to clarify the behavior as:
Client sent configuration for `return_immediately` should be treated as a client preference. Adhering to the behavior specified in 3.1.1, server should retain control over execution and should be able to override client preferences if the request can't be served synchronously.

### Relevant log output

```shell

```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct