feat(strands-memory): add multi-agent support to AgentCoreMemorySessionManager

[tejaskash]

Summary

Adds multi-agent support to AgentCoreMemorySessionManager by tagging every message event with agentId metadata and filtering on read. This allows multiple agents to share the same session while each only seeing its own messages — no config flags or breaking changes required.

Key changes:

• create_message(): always attaches {agentId: agent_id} metadata to both conversational and blob events (immediate and batched paths)
• _flush_messages_only(): groups buffered messages by (session_id, agent_id) so each agent gets its own batched event with correct metadata
• list_messages(): filters by agentId metadata first; falls back to unfiltered query when the filtered result is empty (backward compat for pre-existing sessions)
• initialize(): allows multiple agents per session (info log replaces warning gate)

Backward compatibility: Sessions created before this change don't have agentId on message events. The fallback in list_messages() handles this by retrying without the filter when the filtered query returns empty.

Part of #149 (multi-agent portion). Metadata portion is in #339.

Test plan

• 11 new unit tests in TestMultiAgentSupport class covering: metadata tagging on create, blob path, empty agent_id, list filtering, fallback, initialize multi-agent, batched grouping
• All 134 unit tests pass (123 existing + 11 new)
• Full test suite: 1098 passed, 0 failed
• 2 new integration tests: test_multi_agent_conversation (two agents, disjoint events), test_multi_agent_with_batching (batching + context manager flush)
• Integration tests require dev account (see TESTING.md)

[Hweinstock]

Looks like linter is failing:

tests/bedrock_agentcore/memory/integrations/strands/test_agentcore_memory_session_manager.py:2547:121: E501 Line too long (131 > 120)
     |
2545 |         with batching_session_manager._message_lock:
2546 |             batching_session_manager._message_buffer.append(
2547 |                 ("test-session", "agent-1", [("user", "test message")], False, batching_session_manager._get_monotonic_timestamp())
     |                                                                                                                         ^^^^^^^^^^^ E501
2548 |             )
     |

Found 1 error.

[Hweinstock]

Some high-level questions for my own understanding:

• what is the advantage of adding support for multiple agents to share the same session, v.s. asking customers to build a session per agent? Is this approach effectively a shared memory?
• how exactly does this change the consumer's experience? Is it allowing them to access features of AgentCore/Strands that they couldn't otherwise? Is multi-agent already something supported by both sides that we simply haven't wired up yet?

[jariy17]

Since two agents can share the same session_id, you will have two conversations. This will cause LTM to create memory records based on these two conversations, instead of one. Therefore, we need the memory team to support creating different memory records on different metadatas.