fix: reject terminal tasks before persisting push config (V2) - #1178

What changed

1. Check terminal task state before persisting the push config (V2 handler)

Problem: In DefaultRequestHandlerV2._setup_active_task() (src/a2a/server/request_handlers/default_request_handler_v2.py), the push-notification config was written to the store via set_info() before the terminal-state check ran inside ActiveTask.start(). As a result, sending a message to an already-completed/canceled/failed/rejected task with a task_push_notification_config in the request still persisted the config for that terminal task. V1's handler checks terminal state before any persistence.

Fix (src/a2a/server/request_handlers/default_request_handler_v2.py):

• When message.task_id is provided and the task exists, the terminal-state check now runs immediately after loading the task and before the request-context build / set_info() call, matching V1's ordering (default_request_handler.py _setup_message_execution).
• Raises the same InvalidParamsError("Task {id} is in terminal state: {state}") that ActiveTask.start() raised before, so the error contract is unchanged; the start() check remains as a second line of defense.

Testing

• ./.venv/Scripts/python -m pytest tests/server/request_handlers/test_default_request_handler_v2.py -q → 63 passed.
• ./.venv/Scripts/python -m pytest tests/server/request_handlers/test_default_request_handler.py tests/utils/test_task.py -q → 82 passed (V1 unaffected).
• Updated the two existing on_message_send / on_message_send_stream terminal-state tests to seed the terminal task through the task store (the check now runs earlier than the patched TaskManager.get_task), and added a new parametrized regression test test_on_message_send_terminal_task_skips_push_config_persistence asserting set_info is never awaited for terminal tasks.
• ./.venv/Scripts/python -m ruff check on modified files: clean (the pre-existing too-many-positional-arguments finding on the handler __init__ exists on main).
• Behavior change: push configs are no longer persisted for terminal tasks; the error raised to the client is unchanged.