fix(auth): serialize concurrent xAI OAuth write-through to global root

[sprmn24]

What does this PR do?

_write_through_xai_oauth_to_global_root() syncs a freshly-refreshed xAI OAuth token set from a profile store back to the global root auth.json. The function held the profile-scoped file lock while doing so, but performed the read-modify-write on the global auth.json without acquiring any lock on that file.

When two profiles refresh their xAI tokens concurrently:

1. Profile A and Profile B each read the global auth.json (both see refresh_token_old)
2. Profile A writes refresh_token_A → global file
3. Profile B writes refresh_token_B → global file (overwrites A's token)
4. Profile A's in-memory state has refresh_token_A but the file now has refresh_token_B
5. Next refresh attempt by Profile A: invalid_grant → forced re-authentication

Related Issue

Adjacent to the already-fixed concurrent refresh race in #10147 / #15120 (Nous OAuth). Same class of bug, new code path.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• 🔒 Security fix

Changes Made

• hermes_cli/auth.py: Added _global_root_lock_holder = threading.local() (separate from _auth_lock_holder to prevent _file_lock's reentrancy depth counter from silently skipping the global lock when called from within a profile lock). Wrapped the entire read-modify-write in _write_through_xai_oauth_to_global_root() inside _file_lock(global_path.with_suffix(".lock"), _global_root_lock_holder, AUTH_LOCK_TIMEOUT_SECONDS, ...), matching the .lock sidecar convention used by _auth_lock_path().

• tests/hermes_cli/test_xai_oauth_writethrough.py: Added test_concurrent_write_through_does_not_lose_second_token — fires two threads simultaneously via threading.Barrier(2), asserts the final global auth.json holds exactly one complete token set (not a corrupted mix of access_token from A and refresh_token from B).

How to Test

pytest tests/hermes_cli/test_xai_oauth_writethrough.py -v

All 5 tests pass.

Checklist

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: Windows 11 + WSL2 Ubuntu

[teknium1]

Thanks for targeting a real current-main race in the xAI root write-through path.

Problems

• The new lock covers only hermes_cli/auth.py:4041-4054. The credential-pool companion path still updates the same global file without a lock at agent/credential_pool.py:529-537, and calls it for xai-oauth at agent/credential_pool.py:975-995. A pool refresh can still race this path.
• The added assertion at tests/hermes_cli/test_xai_oauth_writethrough.py:229 accepts either complete final token set. Since _save_auth_store already atomically replaces a complete JSON payload (hermes_cli/auth.py:1137-1153), the unlocked last-writer-wins implementation also satisfies that assertion.

Suggested changes

• Share one global-root auth-store locking helper between both write-through paths.
• Add a deterministic cross-path concurrency test that proves independent root-store updates are preserved, or directly instruments critical-section exclusion.

Automated hermes-sweeper review.

[teknium1]

This lock protects only the non-pool helper. agent/credential_pool.py:529-537 performs the same global-root read-modify-write for xai-oauth without taking this sidecar lock, so a pool refresh can still race this code. Please share the global-root locking mechanism with that helper.

[teknium1]

This accepts the pre-fix last-writer-wins result as well: _save_auth_store already atomically replaces a complete JSON payload. Please make the test observe mutual exclusion or assert preservation of independent concurrent root-store updates.

[teknium1]

Closing as superseded: PR #65656 (salvage of #65264 by @dschnurbusch, merged today) generalized this fix — global-root write-through is now serialized under a lock keyed to the target store's canonical path via _persist_provider_state_to_store(), covering the xAI path this PR addressed plus the Codex/credential-pool sibling sites, and fixing the shared-threading.local reentrancy mis-keying that a single _global_root_lock_holder would have carried. You spotted this lost-update window first — thanks for the report and the fix; the merged version credits the same bug class.