Emit a warning instead of a silent failure when zstd is missing

Issue

I recently attempted to save and restore a cache between my self-hosted OSX runners and the GH-hosted ones. However I was unable to get this working, as I receiving a key not found error.

Background

It came down to the fact that the compression tool is a hidden flag on the cache (the "version"). Which I had a lot of trouble discovering (UI, API calls, error messages, or default logs).

Only when I executed both the save and restore with debug logging enabled was I able to determine zstd was missing on my on-premise hosts.

Examples:
On-premise save logs:

##[debug]Checking zstd --quiet --version
##[debug]Unable to locate executable file: zstd. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

vs. GH-hosted restore logs:

##[debug]Checking zstd --quiet --version
##[debug]1.5.5
##[debug]zstd version: 1.5.5

This is with enableCrossOsArchive enabled on both sides.

Request

To make this kind of failure more obvious to users, I'd like to propose:

• Warn on missing zstd, it seems to be the suggested/desired compression tool on all OS's by the action.
• Log if there are other cache hits for this key that were skipped due to incompatible versions (perhaps message is sensitive to the state of enableCrossOSArchive?).

While I now understand how we got this happened, I'd like to make sure others in the future are more easily able to understand and address the issue.

Thank you!

Start by tracing the cache save and restore paths that check for zstd, using the debug log examples as the entry point. Confirm that a missing zstd produces a user-visible warning and that incompatible cache hits are identified in logs, including the enableCrossOsArchive setting.