Add copy fallback when hardlinking hits the filesystem link limit

[ysmaoui]

Fixes #236.

Problem

When bb_worker uses a native build directory, hardlinkingFileFetcher hardlinks cached CAS blobs from the local cache into each action's input root. Filesystems cap the number of hard links per file — NTFS allows 1023. A file shared by a large number of input roots (e.g. a common toolchain input on a high-fan-out build) exceeds the cap, and the hardlink fails with ERROR_TOO_MANY_LINKS on Windows (EMLINK on POSIX). This is wrapped as codes.Internal and the action aborts:

Failed to create hardlink to cached file "...":
An attempt was made to create more links on a file than the file system supports.

On Windows the virtual (WinFSP) build directory avoids hardlinks, but it needs the WinFSP kernel driver installed on the host — not possible on managed Kubernetes (e.g. AKS Windows node pools) — so native is the only option there and the link cap is a hard wall.

Change

When the hardlink fails because the cached file has reached the filesystem's maximum link count, fall back to copying the file into the input root instead of failing. The copy is an independent inode with its own link count, so materialization succeeds. Only the few over-limit hot blobs pay the copy cost; correctness is unchanged because the input root only needs the file's contents, not a shared inode.

The fix is contained to pkg/cas (no bb-storage change). isHardlinkLimitReached is platform-split: ERROR_TOO_MANY_LINKS on Windows, EMLINK elsewhere.

Testing

• New unit test TestHardlinkingFileFetcherCopyFallbackOnLinkLimit exercises the fallback (via EMLINK); bazel test //pkg/cas:cas_test passes.
• windows_amd64 cross-build of //cmd/bb_worker passes.
• golint and the reformat/gofmt gate are clean.