a2a-python DefaultRequestHandlerV2: ActiveTask kept alive after direct Message or input-required response

Finding: In an external report, a2a-sdk 1.1.2, 1.1.5, 1.2.0 and 1.2.1 (Python 3.14, DefaultRequestHandler resolving to DefaultRequestHandlerV2, InMemoryTaskStore) reportedly leave each request's ActiveTask running when the request does not end in a terminal task state. Source: https://github.com/a2aproject/a2a-python/issues/1296. This is an external report; KFA did not reproduce it. Symptom and conditions: The reporter says that after 50 non-streaming on_message_send calls, an executor that returns a direct Message leaves 200 pending asyncio tasks (50 producers, 50 consumers, 100 dispatch loops). An executor that ends in input-required leaves the same count. A control executor that completes the task leaves 0. The reporter says the producer is parked on its request queue and registry entries remain, so the count grows with traffic. In their service they saw about 10 extra pending tasks per minute per pod, growing memory and profiler overhead. These figures are the reporter's, not independently rerun. Cause status: A commenter (association NONE, so not a verified maintainer) says the ActiveTask harness shuts down only on a terminal Task state, and that direct Message handling does not mark it finished or close the request queue. Treat this as an unconfirmed explanation, not a maintainer-confirmed cause. Source: https://github.com/a2aproject/a2a-python/issues/1296#issuecomment-6049704154. Fix status: The same commenter refers to PR #1297, which handles completion for direct Messages in the event consumer. The reporter later said it covers only the direct-Message case (changed to Part of #1296). The input-required case is still open, with a choice between releasing and recreating from the store or a configurable idle timeout. The reporter also noted that a follow-up arriving before the registry's asynchronous cleanup runs was rejected as already completed, which is a design caveat for release-and-recreate. No merge or released version is shown in the supplied sources. Source: https://github.com/a2aproject/a2a-python/issues/1296#issuecomment-6096498000. Workaround (reporter-described, not verified by KFA): subclass the handler, capture the ActiveTask via the private _setup_active_task hook, and call ActiveTask.aclose() after a direct Message is returned. For input-required tasks, call public on_cancel_task after an idle timeout. The reporter says this restores baseline task counts, but it depends on a private hook and is described as fragile. Cancelling writes a CANCELED state, so it may not suit tasks that should remain resumable. Limitations: single external report, no KFA reproduction, no confirmed released fix.