[Bug]: AgenticMemoryMiddleware shared instances can clobber concurrent retrieval tasks

### Summary

`AgenticMemoryMiddleware` keeps the async retrieval task in a single instance-level `_retrieval_task`. If one middleware instance is shared by multiple agents/sessions, a later reply can overwrite the earlier task, and the earlier reply's `finally` block can cancel the later session's retrieval instead of its own.

### Reproduction

At `29b592358c2e983a0d10dd5227316b7a02d8c23a`, this can be reproduced with two concurrent `on_reply` calls on the same middleware instance:

1. Session A starts `on_reply` and creates retrieval task A.
2. Session B starts before A finishes and overwrites `_retrieval_task` with retrieval task B.
3. Session A exits its handler first.
4. A's `finally` cancels the current `_retrieval_task`, which is task B.

In a minimal hook-level reproduction, `cancelled_after_a` contains `sess-b`.

### Expected behavior

Each session/agent should only observe and clean up its own in-flight retrieval task. A reply finishing in session A should not cancel session B's retrieval.

### Actual behavior

The task slot is shared across the middleware instance, so concurrent replies can clobber each other. This can drop a relevant memory hint for the wrong session and can leave the earlier task orphaned.

### Suggested fix

Mirror the isolation pattern already used by `ReMeMiddleware`: keep retrieval tasks in a per-session/agent mapping, consume the matching key in `on_reasoning`, and cancel only the matching task in `on_reply` cleanup. A regression test should cover two concurrent replies sharing one `AgenticMemoryMiddleware` instance.

Start by opening the `AgenticMemoryMiddleware` code and inspecting `on_reasoning` and `on_reply`, focusing on where `_retrieval_task` is stored and cleaned up. Review `ReMeMiddleware` in the same codebase for the per-session/agent task-isolation pattern and mirror that flow so each session cancels only its own retrieval task. Add or update a regression test for two concurrent `on_reply` calls sharing one middleware instance, and verify each session only tears down its own in-flight retrieval. Done when the overwrite/cross-cancel behavior no longer occurs.

由索引模型根據 Issue 內容生成。