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

The specification currently states that message/send can be used "to initiate a new interaction or to continue an existing one" but doesn't explicitly define when follow-up messages (containing a taskId) should be accepted.

This creates ambiguity about whether clients can send messages to tasks in any non-terminal state or only specific ones.

Describe the solution you'd like

Add explicit requirements to the message/send method specification:

• Multi-turn message acceptance: When a message contains a taskId (follow-up message), the server MUST only accept the message if the referenced task is in the input-required state
• Messages sent to tasks in other non-terminal states (submitted, working, auth-required) MUST result in an UnsupportedOperationError (-32004) with message "Task not accepting input"

Rationale:

• Makes the protocol behavior deterministic and unambiguous
• Prevents clients from sending messages to tasks that aren't ready to receive input
• Aligns with the logical flow where only input-required state explicitly signals the task is waiting for user input
• Uses existing error code rather than introducing a new one

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

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