feat: Add Azure Container Apps Dynamic Sessions executor

[ndamulelonemakh]

What does this PR do?

Adds a new AzureDynamicSessionsExecutor (alongside E2BExecutor, ModalExecutor, DockerExecutor, WasmExecutor) so agents can run code in Azure Container Apps Dynamic Sessions — a managed, sandboxed Python runtime with persistent session state.

Highlights

• New smolagents.azure_executors.AzureDynamicSessionsExecutor, exported from the top-level package.
• Authentication via azure.identity.DefaultAzureCredential by default, with:
  • managed_identity_client_id=... kwarg, or
  • AZURE_SESSIONS_MANAGED_IDENTITY_CLIENT_ID env var, or
  • a fully custom access_token_provider callable (no azure-identity required).
• Token caching with 5-minute refresh window.
• File upload/download/list against the session's /mnt/data volume.
• New azure optional dependency (pip install 'smolagents[azure]'), included in all.
• Unit tests covering token provider, request shape, final-answer detection, traceback → AgentError, file ops, cleanup, and managed-identity wiring.
• Reference documentation under docs/source/en/reference/python_executors.md.

Before submitting

• Did you read the contributor guideline?
• Did you make sure to update the documentation?
• Did you write any new necessary tests?

Who can review?

@aymeric-roucher

[VANDRANKI]

This is a solid, well-scoped addition. The architecture follows the existing RemotePythonExecutor pattern cleanly and the test coverage is genuinely thorough. A few observations:

Token caching

The closure-based caching in _default_token_provider_factory has a minor race condition: two concurrent threads could both see cached_token is None or expires < now + 5min as True and both call credential.get_token(). No corruption occurs (both writes are valid tokens and the last write wins), but you get one unnecessary extra call. A threading.Lock around the refresh block would fix it if this executor is ever used from a multi-threaded agent.

download_file path encoding

urllib.parse.quote(remote_path) uses safe="/" by default, so a path like ../../sensitive passes through with slashes intact. Azure's API should reject such traversals server-side, but urllib.parse.quote(remote_path, safe="") would be more defensive on the client side.

Final-answer + traceback interaction

In run_code_raise_errors, if FINAL_ANSWER_EXCEPTION in stderr is true but deserialization fails (the except Exception: pass branch), execution falls through to the "Traceback" in stderr check. If a traceback is also present it raises AgentError rather than propagating the final answer. This seems like a reasonable fallback, but it might be worth a comment to explain the intent - it surprised me on first read.

Test highlights

test_default_token_provider_factory_raises_helpful_error_without_azure_extra is excellent - patching builtins.__import__ is the right way to test the lazy import guard. The request-shape test (test_run_code_raise_errors_posts_expected_request) also pins the exact URL structure, which will catch any accidental API version or query-param regressions.

Overall the implementation is correct, the optional-dependency wiring is done right (lazy import inside the factory, eager import only for requests which is already a core dep), and the documentation example is clear. The concerns above are minor.