fix(e2e-test): Isolate auth locks in spawned test binaries

[MuskanPaliwal]

Closes #2201

The existing auth-go lock isolation only protected code running inside a go test executable. Integration and E2E tests spawn a separately built entire binary, where testing.Testing() is false. That binary therefore fell back to the auth-go user-cache lock directory. On macOS, os.UserCacheDir() ignores XDG_CACHE_HOME, leaving the developer real ~/Library/Caches/auth-go exposed.

The fix

Add ENTIRE_AUTH_LOCK_DIR as an explicit override ahead of the existing in-process test fallback. The CLI package, integration, and E2E TestMains now point it at their test-owned directories so spawned binaries and hooks inherit the isolation.

When the variable is unset, production behavior is unchanged. Auth-go continues using its normal user-cache default.

The repository spawned-binary testing guidance now includes the new isolation variable.

Verification

The focused regression test failed before the resolver change and passed afterward:

TestTokenManagerLockDir_UsesExplicitOverride
before: tokenManagerLockDir() returned the testdirs fallback
after:  tokenManagerLockDir() returned the explicit override

A manual spawned-process check built the CLI with go build, seeded an expired login and refresh token, and ran entire auth token against a local /oauth/token endpoint twice:

• The positive control, with no override, created the auth-go lock under a fake macOS HOME/Library/Caches/auth-go.
• The fixed run created the same hashed lock under ENTIRE_AUTH_LOCK_DIR.
• The fixed run left its fake user-cache auth-go directory absent.
• The local endpoint received both refresh requests, proving both runs exercised the real refresh and lock path.

Automated checks passed:

go test ./cmd/entire/cli/auth -count=1
mise run check

The resolver override and no-override branches also passed together as the blast-radius guard.

[MuskanPaliwal]

Hey @Soph , would appreciate your review here. Thanks :)