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>

sources/src/cache-service-basic.ts

@@ -80,7 +80,28 @@ export class BasicCacheService implements CacheService {
         const cachePaths = getCachePaths(gradleUserHome)
 
         try {
-            await cache.saveCache(cachePaths, primaryKey)
+            // A cacheId of -1 means the save failed: `saveCache` reports the underlying cause and returns
+            // normally, rather than throwing. Warn and continue: caching failures should not fail the build.
+            const cacheId = await cache.saveCache(cachePaths, primaryKey)
+            if (cacheId === -1) {
+                core.warning(
+                    `Basic caching failed to save entry with key \`${primaryKey}\`. See preceding log output for the cause.`
+                )
+                return {
+                    status: 'enabled',
+                    entries: [
+                        entryReport({
+                            primaryKey,
+                            restoredKey,
+                            restoredOutcome: restoredKey
+                                ? '(Entry restored: exact match found)'
+                                : '(Entry not restored: no match found)',
+                            savedOutcome: '(Entry not saved: save failed)'
+                        })
+                    ]
+                }
+            }
+
             core.info(`Basic caching saved entry with key: ${primaryKey}`)
             return {
                 status: 'enabled',