fix(auth): isolate token refresh cancellation between callers

[sylvesterkaczmarek]

Fixes #427.

Return a dependent future to each foreground or joining caller rather than exposing the cache's shared in-flight future. A caller can cancel or complete its own result without cancelling peers, substituting their token, or prematurely launching a chained forced refresh. The provider refresh itself continues and retains ownership of cache publication.

The identity transformation uses Java 8-compatible thenApplyAsync with an explicit common-pool executor, following the repository callback policy without introducing a new executor lifecycle. Provider invocation, refresh thresholds, deduplication and advisory behavior are unchanged. This is independent of #426's refresh-launch exception handling.

Validation

Six deterministic tests cover leader and follower cancellation, later joiners, forced-refresh sequencing, provider failures and retry, caller-local completion, and an advisory control. Five fail on unchanged main and all six pass after the fix. The related auth, credentials and credential-cache suites pass 88 tests.

Kotlin formatting and core-module Kotlin lint passed. Detekt main/test checks passed with their inputs restricted to the two changed Kotlin files, retaining the repository configuration and rules. Full-project Detekt did not complete locally: one attempt exhausted internal temporary space and an external-storage retry hit its JVM memory limit. The successful scoped run used external temporary/cache storage.

Tested on macOS arm64 using JDK 21. Java 8 runtime, full generated API suites and live authentication were not exercised. No public signatures, dependencies, release metadata or workflow changes.

[sylvesterkaczmarek]

The regression and related tests pass locally, with the validation details in the PR description. Could a maintainer approve the pending Actions run?

[tomer-ant]

Closing along with #427. The reasoning is in #427 (comment).