[Bl0ck154]

Problem

The existing AUTH_OPERATION_LOCK is a Tokio mutex within one process. When desktop Switcher and its web-server binary run at once, each process has its own mutex, so OAuth refresh and account switching can race across processes even though accounts.json itself now uses an atomic lock.

Fix

• Introduce an async auth-operation guard that holds the existing in-process mutex and a filesystem lock at ~/.codex-switcher/auth-operation.lock.
• Acquire the file lock using spawn_blocking so waiting for a second process cannot block Tokio's executor.
• Keep a consistent lock order: auth-operation lock before accounts.lock/auth.lock.
• Replace existing guard acquisitions in background and forced token refresh, account switching, and OAuth completion.
• Resolve the lock file path on the async caller thread before spawn_blocking, preserving thread-local test isolation.

Tests

Add a current-thread async regression test: a second auth operation waits while the first holds the guard and proceeds after release. The existing storage tests cover filesystem lock serialization. No production account files or running processes are used by tests.

This is a focused extraction of upstream Lampese#185's cross-process-lock concept, integrated with our workspace-aware OAuth and atomic storage.

Draft until Rust CI and platform compile checks pass. No desktop release or VPS services are changed.