DefaultRequestHandler runs follow-up messages on a task with the first request's contextvars

Finding: In a2a-python DefaultRequestHandler (v2), an external report says a follow-up message on an existing task (for example a reply after input-required) runs AgentExecutor.execute() with the contextvars of the request that created the task, not the follow-up request. Reported on versions 1.1.2 and 1.2.2, for both SendMessage and SendStreamingMessage; 0.3.x is reported unaffected because it started a new producer per message (source: https://github.com/a2aproject/a2a-python/issues/1316). Impact as described by the reporter: per-request contextvars set by ASGI middleware or a ServerCallContextBuilder, such as auth tokens, tenant or caller identity and request-scoped tracing, may be stale in follow-up executions. ServerCallContext.state is reported as correct per message; only contextvars are affected. Because a task parked in input-required keeps its ActiveTask, a later reply may see values from the first request, possibly an expired token (same source). Reported cause (reporter's analysis, a hypothesis not confirmed by a maintainer): ActiveTask.start() creates the producer with asyncio.create_task during the first request, so the producer copies that context once. Later requests call enqueue_request(), which only places the RequestContext on a queue, so execute() keeps running in the first request's context (same source). Reproduction as reported: a Starlette app with middleware setting a contextvar from an x-tag header, an executor that prints it, and two requests where the second is a follow-up on the same task. The reporter says the output shows request-1 for both executions, whereas request-2 was expected for the follow-up. This is an external report; it was not reproduced by KFA. Proposed fix (reported, not shipped as far as the supplied content shows): capture contextvars.copy_context() in enqueue_request(), queue it with the request, and run execute() via that context in _run_producer. The reporter says they applied this locally to 1.2.2 and it printed request-2 for both send modes, and that the MCP Python SDK fixed the same issue similarly in modelcontextprotocol/python-sdk#2298 (not independently supplied here). Status: the issue is closed, but the supplied thread has no comments, no linked fix commit and no release. Closure alone is not evidence of a fix, so fix status is UNKNOWN. Limitations: single external report; no KFA reproduction; maintainer confirmation of cause is absent; comments coverage may omit middle comments.