[richardartoul]

Follow-up to #25. localcache stored each output in a file named after its action ID, with its metadata (output ID and size) in a separate .meta file. #25 made each file's write atomic, but data and metadata are still two separate renames. Two unserialized writers of one action ID with different outputs (for example LOCK_TYPE=memory across processes with a non-reproducible action) can interleave like this:

A: rename data(A)
B: rename data(B)
B: rename meta(B)
A: rename meta(A)   -> data is B's, metadata says A's output ID and size

When the sizes differ, Go's size check turns this into a miss. When they match, the build silently uses the wrong bytes. This matters more once #23 turns a lock timeout into "proceed without the lock".

Change

• Outputs are stored under their output ID (<subdir>/v2<outputID>-d). Go computes the output ID as the SHA-256 of the body, so concurrent writers of one output file write identical bytes. The .meta file under the action ID is now the pointer to that file, as in Go's own disk cache.
• The data is written before the metadata, so whichever metadata wins references a complete file holding exactly its output. write() also skips rewriting an output file that already exists with the right size.
• Metadata files use a .meta2 suffix so they never mix with earlier versions' .meta files (see Compatibility).
• check() now stats the output file and treats a missing or wrongly sized file as a miss (one extra stat per lookup).
• handlePut used to return the existing entry's path whenever the action ID was already cached. cmd/go records the returned DiskPath as the file for the output ID it sent (noteOutputFile(out, res.DiskPath) in cmd/go/internal/cache/prog.go), so for a different output ID that mapped the new output ID to the old bytes. It now short-circuits only when the output IDs match.
• writeWithMetadata rejects an empty output ID instead of building a path from it.

Compatibility

fileFormatVersion is not bumped, because it is also part of the backend key and bumping it would invalidate every remote cache. Instead, metadata now lives in .meta2 files, so this layout and earlier versions never read each other's local entries. Versions sharing one cache directory, or a downgrade, each keep using their own entries. Earlier versions' .meta files and action-ID data files are left untouched.

Testing

• TestLocalCacheConcurrentWritesOfOneActionIDWithDifferentOutputs: 16 writers put one action ID with distinct, same-size outputs while 4 readers keep checking that every hit's metadata matches the bytes in its file. On main it fails 5 of 5 runs, both from readers and in the final entry. Here it passes 30 of 30 runs with -race.
• TestLocalCacheIgnoresEntriesOfEarlierVersions: an entry in the old layout is a miss, and writing the entry again leaves the old .meta and data files unchanged (fails with the .meta suffix).
• TestLocalCacheIgnoresEntriesWithoutOutputFile: metadata whose output file is missing is a miss.
• TestPut_ExistingEntryWithDifferentOutput: a second PUT of one action ID with a different output returns a DiskPath that holds the new output (fails on main).
• go vet . and go test -race . ./pkg/... pass. The cloud-backend integration tests were not run locally.