perf: cache pnpm's lockfile verification results

pnpm v11 and newer verify every lockfile entry against the configured
supply-chain policies (`minimumReleaseAge`, `trustPolicy`, ...) and memoize
the verdict in `<cacheDir>/lockfile-verified.jsonl`. The action cached only
the store, so every job started with that verdict missing and re-checked the
whole lockfile against the registry — on typescript-eslint's repository,
16.6s of a 17.6s install on Linux and 40.1s of 42.4s on Windows.

The verdict depends on the lockfile content and the policies, never on the
runner, so it is cached under its own key alongside the store cache and
restored without prefix fallback: an entry recorded for a different lockfile
could never be reused. Saving happens before `pnpm store prune`, which drops
the log along with the store's other derived state.

Anything that goes wrong here only costs the next job the re-verification, so
failures are reported as warnings instead of failing the build. Older pnpm
versions never write the log, and the post step then finds nothing to save.

src/windows-path/index.ts

@@ -0,0 +1,19 @@
+/**
+ * pnpm may report an extended-length path on Windows. The `?` in that prefix
+ * is interpreted as a wildcard by `@actions/cache`, which rejects it as a glob
+ * in the root segment. Cache APIs do not need the extended-length form, so
+ * convert it back to a regular drive or UNC path.
+ */
+export function removeWindowsExtendedPathPrefix(cachePath: string): string {
+  const extendedPathPrefix = '\\\\?\\'
+  if (!cachePath.startsWith(extendedPathPrefix)) return cachePath
+
+  const pathWithoutPrefix = cachePath.slice(extendedPathPrefix.length)
+  const uncPrefix = 'UNC\\'
+  if (pathWithoutPrefix.toUpperCase().startsWith(uncPrefix)) {
+    return `\\\\${pathWithoutPrefix.slice(uncPrefix.length)}`
+  }
+  return pathWithoutPrefix
+}
+
+export default removeWindowsExtendedPathPrefix