[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 f15b88f

[runningcode]

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

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

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

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

[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)	1735 ms
PR (help PR)	1667 ms
Difference	✅ -68 ms (-3.9%)