Fix basic caching smoke test on Windows, and warn on save failure

[bigdaz]

Follow-up to #1027, which added Windows coverage for the caching smoke tests. basic-cache-verify-build failed on Windows for a reason unrelated to #1013.

Root cause

The Windows seed job never uploaded a cache entry, but reported that it did. gh cache list showed no setup-java-Windows-* entry at all, despite the job logging Basic caching saved entry with key: setup-java-Windows-x64-gradle-594edf…. The keys were never the problem — seed and verify requested the identical key.

The seed build leaves a Gradle daemon running, holding the *.lock files in the Gradle User Home. On Windows those locks are mandatory, so tar cannot read them:

/usr/bin/tar: ../../.gradle/caches/modules-2/modules-2.lock: Read error at byte 0,
              while reading 38 bytes: Device or resource busy
/usr/bin/tar: Exiting with failure status due to previous errors

38 bytes is exactly Gradle's lock-file header — the region the daemon holds via FileChannel.lock(). On Linux the lock is advisory and tar reads straight through, which is why this only ever failed on Windows.

cache.saveCache() catches the tar failure, logs it, and returns -1 rather than throwing. BasicCacheService.save() ignored the return value, so the seed job went green and the failure surfaced only later — as a plugin resolution error in the verify job, pointing nowhere near caching.

Changes

1. Warn when the save fails. Check the returned cacheId and, when it is -1, emit a warning and report (Entry not saved: save failed) in the job summary. Caching failures still do not fail the build.

2. Run the seed build with --no-daemon. Daemon management for enhanced caching lives in the gradle-actions-caching library; basic caching leaves it to the workflow, so the smoke test now ensures no daemon is holding locks when the post-action save runs.

Not related to #1013

The enhanced provider fails differently on Windows — every entry dies at path validation, before tar runs (Path Validation Error: Path(s) specified in the action for caching do(es) not exist). Same symptom, different mechanism; that one is unchanged here and is still expected to be red.

Verification

npm run check and npm test pass locally (373 tests). The real check is this PR's Windows run: basic-cache-seed-build and basic-cache-verify-build should both be green on windows-latest, while the restore-gradle-home-* Windows jobs stay red pending the #1013 fix.

🤖 Generated with Claude Code