Change 243b4d broke config processing/auth flow for configs with a userid and password

Describe the bug

See https://github.com/jfrog/jfrog-cli/issues/3445 for the full debug trace, but wanted to post this here since this is the actual repo owning the breaking change.

jf c add with username and password
After v2.100 - this can't get updated to username+access token automatically.

Current behavior

Prior to v2.100 - 'jf c add' with a username and password followed by a 'jf search' - would result in a config file with a refreshable access token. After v2.100 - it stays as username/password, but has all sorts of intermittent failure behaviors because of all of the 401's being generated by this area of changed code in createTokensForConfig()

+       // If basic auth failed and a password is available, retry using it as a Bearer token.
+       // This handles reference tokens, which the Access service can resolve server-side.
+       if serverDetails.Password != "" {
+               bearerDetails := serverDetailsForBearerAuth(serverDetails, serverDetails.Password)
+               servicesManager, err = createAccessTokensServiceManager(bearerDetails)
+               if err != nil {
+                       return auth.CreateTokenResponseData{}, err
+               }
+               newToken, err = servicesManager.CreateAccessToken(createTokenParams)
+               if err == nil {
+                       return newToken, nil
+               }
+               log.Debug("Access token creation with Bearer auth failed: " + err.Error())
+       }

cause the password isn't a bearer token. It leaves the client/etc. "sortof able to work" - but it seems entirely dependent on the pattern/timing of operations on whether it gets lots of failure states due to recurrent failure errors.

Reproduction steps

See https://github.com/jfrog/jfrog-cli/issues/3445 for the full debug trace, but wanted to post this here since this is the actual repo owning the breaking change.

Expected behavior

Login and conf updates to still function as they did before.

NOTE - no impact if it's a reference token, it works fine in that scenario.

JFrog CLI-Core version

v2.60.1-0.20260414083544-243b4d55328b vs v2.60.1-0.20260402104745-7a0bc2c11d63

JFrog CLI version (if applicable)

v2.100.0

Operating system type and version

Debian 12

JFrog Artifactory version

7.146.7

JFrog Xray version

No response

Start by reviewing createTokensForConfig and the change in commit 243b4d55328b, then compare it with the preceding 7a0bc2c11d63 behavior. Use the debug trace in jfrog-cli issue 3445 to reproduce the username/password flow, and verify that login and config updates work again without breaking reference-token handling.