feat: add MemoryClient for control plane + data plane passthrough

[Hweinstock]

Description

Add MemoryClient for Bedrock AgentCore Memory, covering both control plane and data plane operations.

Uses a Proxy with declaration merging to expose a curated set of AWS SDK methods as direct passthroughs on the client.

.memory(memoryId) returns a scoped ScopedMemory that auto-injects the memoryId into every call, reducing repetition when operating on a single memory.

Convenience methods for common workflows:

• createOrGetMemory — idempotent create (falls back to get on conflict)
• createMemoryAndWait / deleteMemoryAndWait — polling wrappers
• waitForMemories — polls until LTM extraction produces records
• getLastKTurns — retrieves the last K conversation turns grouped by USER boundaries
• listBranches — aggregates branch info from events

Core design decisions vs Python SDK:

• Single class instead of Python's 3 (MemoryClient, MemoryControlPlaneClient, MemorySessionManager)
• No strategy helpers — SDK's UpdateMemoryCommand already has full typed configs
• No response normalization or wrapper models — TS SDK types are canonical
• Strands integration will not live here and will be decoupled from core memory functionality

NOTE: Not yet published into the vended SDK, no entry in the package.json exports map. Will be added once integration tests are in place.

Testing

Unit tests use dependency injection (injectable SDK clients via MemoryClientConfig) with simple fakes to avoid mocks. Tests verify:

• Passthrough routing: every data plane and control plane method is exposed as a function on the real client
• ScopedMemory: scoped methods are callable
• Convenience methods: createOrGetMemory conflict handling, deleteMemoryAndWait polling, getLastKTurns turn boundary parsing, listBranches aggregation

Type of Change

New feature

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

#125
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jariy17]

I like this design, but I dont understand the benefits of having a ScopeMemory. Could you explain why a customer just provide the memoryId themselves each time they call createEvent and similar functions?

[Hweinstock]

mostly verbosity, there is no reason they can't manually provide an ID each time. I saw it as concise way to combine a memory-scoped client, and a raw SDK client into a single interface. The same functionality is split between clients in the existing python implementation.

Happy to leave it out, if we think its awkward/wont be used.

[jariy17]

lets leave it out for now