[Kayvan-Zahiri]

A transient result-fetch error inside task_run.execute reaches a generator context manager that yields again after catching the error. Python raises RuntimeError: generator didn't stop after throw() instead of repeating the fetch. This affects both sync and async execution once a read timeout or HTTP 408/503/504 escapes the HTTP client's own retries.

Run the retry loop around the callable itself, retaining the existing status allowlist, monotonic deadline, and final TimeoutError cause. Remove the invalid context manager and colocate its error helpers with the retry callers. Generated resources and dependency metadata are unchanged.

Tests exercise public sync/async execute through HTTPX MockTransport with the inner HTTP retry disabled, then assert successful recovery. Additional checks cover 429 propagation, expired deadlines without requests, and timeout causes. No live API/account calls.

Validation on Python 3.12:

• Before: eight transient-error cases fail; two 429 controls pass.
• After: 14 focused tests pass; broader offline suite 486 passed, two skipped.
• Full Ruff lint passes. Changed files format cleanly; README and generated task_run.py have existing formatting differences and are unchanged.
• Full Pyright passes; Mypy reports one error in the unchanged _utils/_typing.py. Sdist/wheel and diff check pass.

The repository development lock cannot resolve as written (virtualenv requires a newer filelock than pinned). Used an isolated environment with repository-pinned Pydantic, typing-extensions, type checkers and build backend, plus compatible test tools. Mypy has a typing.TypeAliasType tuple incompatibility under the local 3.12 interpreter; it also reproduces on the untouched baseline. Resource tests requiring the mock API server and the Python/Pydantic version matrix were not run.