fix: coordinate refresh token persistence

[ElgoogUdiab]

Concurrent account and MCP commands can rotate the same saved refresh token, and a read-only sandbox can consume a token without saving its replacement. This change verifies credential-store writes before issuance and coordinates refresh and persistence across CLI processes.

• Use a per-credential proper-lockfile directory lock on Linux, macOS, and Windows. Reload credentials under the lock, reuse a newer valid token, and keep the lock until the response is consumed and the rotated credentials are atomically saved.
• Coordinate login persistence and logout with refresh; SDK save callbacks acknowledge persisted responses without overwriting newer credentials. Failed SDK recovery leaves disk credentials intact. Compromised locks abort the request, and abandoned locks expire after 60 seconds.
• Add six regression tests covering four independent account/MCP processes, same-provider concurrency, delayed SDK saves after logout, network/response failures, killed owners, and lock compromise. Retain the read-only sandbox regression tests.

Validation: all 52 tests, lint, formatting, types, and packed installation checks pass locally. Installation checks cover npm global/local/one-off execution, pnpm 10, and Yarn Classic. CI runs the same checks on Linux, macOS, and Windows with Node.js 22 and 24.

Companion backend recovery: https://github.com/DeemosTech/hyper3d-backend/pull/541. Local locking does not recover a response lost after server-side rotation; no automatic network or business-operation retry is introduced. Older CLI versions sharing the credential directory do not participate in the locking protocol.