fix(tools): serialize concurrent hermes_tools RPC calls from execute_code

[vominh1919]

Summary

When a script run via execute_code calls hermes_tools functions (terminal, read_file, etc.) from multiple threads (e.g. ThreadPoolExecutor), each thread frequently receives another thread's response.

Root Cause

UDS transport (local backend): All threads share a single socket (_sock). Concurrent send+recv interleaves.

File transport (remote backends): The global _seq counter has a race condition — two threads can get the same seq number.

Fix

Transport	Problem	Fix
UDS	Shared socket, no serialization	threading.Lock() around send+recv
File	_seq race condition	threading.Lock() around _seq increment

Fixes #17770

[alt-glitch]

Likely duplicate of #17771 — identical fix (threading.Lock on UDS send+recv and file transport seq) for the same #17770 race condition in code_execution_tool.py.

[alt-glitch]

Likely duplicate of #17771

[alt-glitch]

Likely duplicate of #17771

[alt-glitch]

Likely duplicate of #17771

[teknium1]

Thanks for tackling this! Closing in favor of #17902 which went with @Heltman's #17771 (he filed the original issue #17770 a few hours earlier). Two things your version would have hit in production that the merged one avoids:

1. The file-transport header uses with _seq_lock: but never declares _seq_lock and doesn't add threading to the import line — any remote backend (Docker/Modal/SSH) would have raised NameError on the first RPC call.
2. The payload still does "seq": _seq (module global) outside the lock, so the filename (seq_str) and the payload's seq field can disagree under contention.

The merged fix snapshots seq into a local under the lock and uses that local everywhere, plus adds a full E2E regression test through execute_code. Appreciate you diagnosing it independently — right instinct, same root cause analysis.