fix(logging): alias RotatingFileHandler to concurrent-log-handler (salvage #44921)

[austinpickett]

Summary

Salvage of #44921 (@tuancookiez-hub) onto current main. Fixes #44873.

On Windows, stdlib RotatingFileHandler.doRollover() uses os.rename(), which fails with PermissionError [WinError 32] whenever another process holds an append-mode handle on agent.log — essentially always in Hermes, where the TUI, gateway, hy_memory server, MCP servers, and on-demand CLI commands all log from separate processes. The result: agent.log gets pinned at the 5 MiB rotation threshold and every emit spams stderr with a traceback.

Confirmed still present on main: hermes_logging.py:35 still does from logging.handlers import RotatingFileHandler, and there's no concurrent-log-handler anywhere in pyproject.toml.

What changed

• Add concurrent-log-handler==0.9.29 as a core dependency
• Alias its ConcurrentRotatingFileHandler as RotatingFileHandler in hermes_logging.py — it wraps the rename in a cross-process file lock (via portalocker: pywin32 on Windows, fcntl on POSIX) so only one process rotates at a time and the others wait their turn
• The alias keeps every existing reference working unchanged: _ManagedRotatingFileHandler(RotatingFileHandler) still subclasses correctly, and all isinstance(..., RotatingFileHandler) checks still match
• Test file uses the same alias so its autouse-fixture handler-stripping matches the CLH-backed class

Deviation from the original PR

Tidied a minor inaccuracy in the explanatory comments: the original said the lock uses "msvcrt on Windows, fcntl on POSIX", but CLH 0.9.29 actually locks via portalocker (which uses pywin32 on Windows). Updated both the module and pyproject comments. No functional change.

Test plan

• uv lock --check → consistent (220 packages); portalocker pulled transitively (pywin32 already a core dep)
• Import E2E: hermes_logging.RotatingFileHandler is ConcurrentRotatingFileHandler → True; _ManagedRotatingFileHandler subclasses it → True
• pytest tests/test_hermes_logging.py → 60 passed. The 2 failures observed locally (*_group_writable) are pre-existing Windows-only failures — they assert 0o660 Unix perms with no skipif guard and fail on main too; CI runs on Linux where they pass.

Credit

• fix(logging): alias stdlib RotatingFileHandler to concurrent-log-handler (#44873) #44921 by @tuancookiez-hub — authorship preserved on the commit

[github-actions]

🔎 Lint report: salvage/win-log-rotation-44921 vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10949 on HEAD, 10949 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5762 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[OutThisLife]

Approving. Clean salvage, and a meaningful improvement over the original #44921: scoping the swap to Windows only (sys.platform == 'win32' import + sys_platform == 'win32' dependency marker) is the right call —

• The bug (os.rename WinError 32 on a file another process holds open) is Windows-specific; POSIX renames an open file fine, so stdlib already works on Linux/macOS.
• The POSIX managed-mode (NixOS) path depends on stdlib RotatingFileHandler's exact _open()/doRollover() lifecycle for the 0o660 chmod; keeping stdlib there preserves that guarantee, which CLH's lazy-open/different-rollover would break.
• _ManagedRotatingFileHandler stays constructor-compatible with ConcurrentRotatingFileHandler (only maxBytes/backupCount/encoding are passed, all supported), and on Windows _chmod_if_managed is a no-op since is_managed() is False there — so the super() delegation in _open/doRollover is clean.
• ==0.9.29 matches this repo's exact-pin convention for core deps; uv.lock is regenerated with the portalocker/pywin32 tree correctly gated on sys_platform == 'win32'.
• The test imports RotatingFileHandler from the module under test so the autouse strip fixture matches whichever class resolved, on either platform.

The Windows CLH path can't execute on the Linux CI runners, but the delegation is sound and the "Windows footguns" check passes. LGTM.