Fix basic caching smoke test on Windows, and warn on save failure (#1028)

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](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

.github/workflows/smoke-test-basic-cache-provider.yml

@@ -39,9 +39,12 @@ jobs:
       with:
         cache-provider: basic
         cache-read-only: false # For testing, allow writing cache entries on non-default branches
+    # Basic caching does no daemon management, so the workflow must ensure no daemon is left
+    # holding locks on the Gradle User Home when the post-action save runs. Without this, `tar`
+    # cannot read the Gradle '*.lock' files on Windows and the cache entry is never saved.
     - name: Build kotlin-dsl project
       working-directory: .github/workflow-samples/kotlin-dsl
-      run: ./gradlew build
+      run: ./gradlew build --no-daemon
 
   basic-cache-verify-build:
     needs: basic-cache-seed-build