refactor: reuse the Lambda client

[leandrodamascena]

closes #249

Description of changes:

This PR refactor the Lambda client creation to reuse the same client when the execution happens in a existing sandbox.

I went with a simple module-level global variable for caching the boto3 client. Lambda sandboxes process one request at a time (and in LMI multi-concurrency) is per process, so there's no real concurrent access to worry about. Adding a lock would just introduce overhead on every call without any practical benefit. In the unlikely event of a race condition, the worst that happens is we create two clients and one gets garbage collected - no corruption or crashes.

Please let me know if this implementation make sense.

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

[leandrodamascena]

We have a rule enabled in Ruff to discourage this. Ok, I didn't know, I'll transform in in a classmethod then.

[leandrodamascena]

I changed from staticmethod with global var to classmethod with class-level attribute.

[leandrodamascena]

Python 3.14 is failing.. maybe the runner?

[yaythomas]

for a different day, currently Any because there isn't a built-in boto type we can use without adding more imports.

since we're only using 2 methods, might be an idea to create a protocol:

from typing import Protocol

class DurableLambdaClient(Protocol):
    def checkpoint_durable_execution(self, **kwargs) -> dict: ...
    def get_durable_execution_state(self, **kwargs) -> dict: ...

[leandrodamascena]

for a different day, currently Any because there isn't a built-in boto type we can use without adding more imports.

since we're only using 2 methods, might be an idea to create a protocol:

from typing import Protocol

class DurableLambdaClient(Protocol):
    def checkpoint_durable_execution(self, **kwargs) -> dict: ...
    def get_durable_execution_state(self, **kwargs) -> dict: ...

I think we should consider using mypy-boto3-lambda instead of creating a custom Protocol. If we want proper type checking, a Protocol for duck typing won't bring much benefit here - today it's 2 methods, tomorrow it could be more, and we'd need to maintain it ourselves or just add classes to remove Any, honestly idk if this is the right direction.
The boto3 stubs are widely used in the community and would be a dev dependency only, not shipped with the package - just used for static analysis during development.

I'm happy to explore this in a follow-up PR if you're open to it. But pls let me know if you want me to add this class now, it's easy.

[yaythomas]

I wasn't sure how "standard" mypy-boto3-lambda is, good to hear it's got wide adoption...

and yes, adding it as dev dependency is reasonable :-)

[yaythomas]

Python 3.14 is failing.. maybe the runner?

looks like a non-deterministic test to me, assert should prob not demand order, instead

    # Verify we have exactly 2 calls with the expected child IDs (in any order)
    assert len(operation_ids) == 2
    assert set(operation_ids) == {"child-0", "child-1"}

[leandrodamascena]

Hey folks! I'm pushing a commit today with some changes.