Rush CLI 0.2.43

Daemon shutdown no longer abandons an in-flight token write — which could clobber the real ~/.rush/user.yaml and log the owner out (PHNX-3952). daemon.Stop() shut the UDS server down with a fixed 5s deadline; http.Server.Shutdown returns when that deadline elapses but does not cancel a still-running handler, so under refresh contention a /token write handler outlived Stop(). In a test that pinned the home dir via paths.SetHomeForTest, that straggler resolved paths.RushHome() after the override reset and wrote the test fixture (email: test@example.com, a refreshed_at refresh) over the developer's real user.yaml — the failure that broke the 0.2.42 upload. The UDS server now tracks only in-flight /token handlers and Stop() waits for those credential operations to return; unrelated UDS work remains bounded by the shutdown context. paths.homeOverride is also now mutex-guarded, removing the data race the leak rode on. No user-facing command or output changed.

macOS: stop the recurring "A keychain cannot be found to store __rush_keychain_probe__" modal (PHNX-3954). The keychain write (the keychainAvailable() probe on every save, and every token store) now targets the login keychain explicitly instead of relying on security's default-keychain resolution. From a launchd/daemon session with no resolvable default keychain, that resolution popped an interactive SecurityAgent modal and blocked — re-firing on every save, so the daemon and its 30-min token-refresh flooded users with dialogs. Naming the keychain makes an unresolvable/locked keychain error into the existing plaintext-user.yaml fallback rather than prompt. Secrets still go over stdin (never ps-visible argv) and keep go-keyring's encoding, so stored items stay cross-readable. Regression introduced with RUSH-632 (2026-07-19).