fix(cli): tightening the credentials lock file is best effort (BUG-3649)

Both pilot bug-hunters (Haiku and Sonnet, blind): fchmod on a lock file
another uid owns returns EPERM, which failed every UpdateStore and so
every login. The lock file holds no secret, and the token's protection
is credentials.json's own 0600 temp-plus-rename, so the chmod error is
ignored and the lock is still taken. The owner-case tightening test
stays. (Lead ruling: accepted.)

Claude-Session: https://claude.ai/code/session_01Rj4CMyK2EqxerMihbGs3Kr

internal/cli/credentials_lock_unix.go

@@ -16,11 +16,11 @@ func lockCredentialsFile(lockPath string) (unlock func(), err error) {
 		return nil, err
 	}
 	// The mode on OpenFile applies only on creation (BUG-3648's class), so
-	// an existing lock file is tightened here (Codex round 1).
-	if err := f.Chmod(0600); err != nil {
-		_ = f.Close()
-		return nil, err
-	}
+	// an existing lock file is tightened here (Codex round 1). Best effort:
+	// a lock file this user does not own (left by a sudo run) refuses fchmod
+	// with EPERM, and the lock file holds no secret, so that must not turn a
+	// working login into a failure (bug-hunter pilot, lead ruling).
+	_ = f.Chmod(0600)
 	if err := syscall.Flock(int(f.Fd()), syscall.LOCK_EX); err != nil {
 		_ = f.Close()
 		return nil, err