[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.