[DNM] [TEST] fix(config-cache): Defer CLI path resolution to execution phase

[runningcode]

Just testing do not review.

Summary

• Defer sentry-cli path resolution from Gradle's configuration phase to execution phase, fixing recurring build failures when the configuration cache stores a stale CLI binary path
• Remove SentryCliValueSource, cliExecutableProvider(), and the cliExecutable @Input property from all tasks — CLI path is now resolved fresh inside computeCommandLineArgs() at task execution time
• Remove SentryCliInfoValueSource and SentryCliVersionValueSource which spawned sentry-cli processes during configuration phase; use BuildConfig.CliVersion and URL-based SaaS heuristics instead
• Improve maybeExtractFromResources() to handle CLI version mismatches by extracting the current bundled version when a stale path from a previous plugin version is detected

Fixes #613
Fixes GRADLE-70

Root Cause

The CLI path was resolved during configuration via SentryCliValueSource and cached by Gradle's configuration cache. This cached path became stale in two scenarios:

1. Version mismatch on plugin upgrade: Config cache stored sentry-cli-2.46.0.exe but the upgraded plugin ships sentry-cli-2.51.1.exe. The old recovery code in maybeExtractFromResources() only re-extracted when paths matched exactly, so sentry-cli-2.46.0.exe != sentry-cli-2.51.1.exe caused it to skip extraction.

2. Binary deleted: The extracted CLI binary was cleaned up (OS temp cleanup, ./gradlew clean, or daemon restart) while the config cache still held the old path.

Approach

Rather than patching the config cache inputs, we eliminate the problem entirely by not caching the CLI path at all. The path is resolved fresh during each task's execution phase, which is the correct time to do filesystem I/O.

This also removes the telemetry ValueSources that executed sentry-cli info and sentry-cli --version during configuration phase (~38% overhead on large projects per #1100).

🤖 Generated with Claude Code

[linear-code]

GRADLE-70

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

### Features

- Defer CLI path resolution to execution phase ([#1224](https://github.com/getsentry/sentry-android-gradle-plugin/pull/1224))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against 6bb80e1

[runningcode]

we don't actually want the contents of these directories as inputs

[sentry]

Bug: The unsynchronized started() method in SentryTelemetryService creates a race condition when accessing pendingOrgLookupParams, which is set by the synchronized start() method.
_{Severity: MEDIUM}

Suggested Fix

Add the @Synchronized annotation to the started() method in SentryTelemetryService to ensure thread-safe access to the pendingOrgLookupParams field. Alternatively, annotate the pendingOrgLookupParams field with @Volatile to ensure memory visibility across threads.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
plugin-build/src/main/kotlin/io/sentry/android/gradle/AndroidComponentsConfig.kt#L275-L276

Potential issue: A race condition exists in `SentryTelemetryService`. The `start()`
method is `@Synchronized` and sets the `pendingOrgLookupParams` field. However, the
`started()` method, which reads and nullifies this field, is not synchronized. During
parallel Gradle builds, multiple threads can call `started()` concurrently. This can
lead to a race condition where the write to `pendingOrgLookupParams` during the
configuration phase may not be visible to threads reading it in the execution phase, due
to a lack of memory visibility guarantees.

Also affects:

• plugin-build/src/main/kotlin/io/sentry/android/gradle/telemetry/SentryTelemetryService.kt:115~119

[github-actions]

help configuration benchmark (configuration cache disabled)

Mean of 5 builds after 2 warm-ups.

Scenario	Mean build time
Base (help base)	1870 ms
PR (help PR)	1818 ms
Difference	✅ -52 ms (-2.8%)

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 98cbe06. Configure here.}

[sentry]

Bug: The SentryTelemetryService has a race condition. The attachDefaultOrg method lacks synchronization, allowing concurrent tasks in parallel builds to cause redundant operations and inconsistent state.
_{Severity: MEDIUM}

Suggested Fix

Ensure thread-safety in SentryTelemetryService. Synchronize the access to the orgAttached flag and the subsequent scope configuration within the attachDefaultOrg method. This can be achieved by using a synchronized block or leveraging thread-safe constructs like AtomicBoolean.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
plugin-build/src/main/kotlin/io/sentry/android/gradle/telemetry/SentryTelemetryService.kt#L209-L221

Potential issue: The `SentryTelemetryService`, a Gradle `BuildService`, is not
thread-safe. The `attachDefaultOrg()` method, called during task execution, contains a
check-then-act race condition on the `orgAttached` flag. In parallel builds, multiple
tasks can call this method concurrently, pass the `orgAttached == false` check, and
proceed to configure the Sentry hub's scope simultaneously. This leads to a data race
and can result in redundant operations and inconsistent telemetry state, as the service
is shared across all tasks without serialization constraints.

[sentry]

Bug: The SentryOrgValueSource spawns a sentry-cli process during Gradle's configuration phase on every build, causing a performance overhead that the PR intended to remove.
_{Severity: MEDIUM}

Suggested Fix

Refactor SentryOrgValueSource.obtain() to avoid spawning an external process. The organization information should be obtained through a different mechanism that is compatible with Gradle's configuration cache, or the operation should be deferred to task execution time without using a ValueSource that triggers this behavior.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
plugin-build/src/main/kotlin/io/sentry/android/gradle/SentryCliProvider.kt#L224-L274

Potential issue: The `SentryOrgValueSource.obtain()` method is called by Gradle on every
build to check the configuration cache fingerprint. This method spawns a `sentry-cli
info` external process to retrieve organization information. As a result, this
subprocess is executed during the configuration phase of every build, even when the
configuration is cached. This negates the performance improvements intended by the pull
request, which aimed to eliminate such processes from running during the configuration
phase.