ci: key Windows sccache cache on MSVC version

[abnobdoss]

What

Add the cl.exe version to the Windows sccache cache key (and its restore-keys prefix) in test and sql_catalog_test, so each MSVC build keeps its own cache. On the sql_catalog_test matrix the suffix stays empty for the non-Windows legs, so their keys don't change.

Why

sccache decides whether a cached object is still valid from the compiler binary. GitHub patches the Windows runner image regularly, roughly once a week, and rolls each update out across the hosted fleet over a few days rather than all at once. During that window back-to-back runs can land on different cl.exe builds. When that happens the two builds share one cache key and keep evicting each other, and a run on a newer compiler restores the old cache, misses everything, and rebuilds the whole stack (around 35 to 50 minutes). Putting the cl.exe version in the key gives each compiler its own cache, so a run stays warm instead of recompiling.

Validation

On the windows-2025 runner the resolve step read cl.exe as 19.51.36248, and the Windows test and sql_catalog_test builds passed with the version in the key. The cache is only saved on main, so the warm reuse shows up there rather than on a branch run.

[zhjwpku]

Let's see how it goes.

[wgtmac]

Thanks @abnobdoss for improving this!