chore(ci)(deps): bump actions/setup-node from 4.4.0 to 6.4.0 - #4857

…ABI mismatch (#4938)

## Summary

Fixes a probabilistic CI failure in the `test / unit` matrix where Node
20.x and 22.x jobs would fail with `Module did not self-register` on
`better-sqlite3`.

### Root cause

`setup-node`'s built-in `cache: "pnpm"` uses a cache key of
`node-cache-Linux-pnpm-{lockfileHash}` — **no Node.js version in the
key**. All three matrix jobs (Node 20, 22, 24) share one cache entry.

The failure is **probabilistic, not always-present**:

- **Cold run (first after cache reset):** all three jobs install fresh
and pass. Whichever job finishes first writes its ABI-specific
`better-sqlite3` binary to the shared cache key.
- **Warm run (all subsequent runs):** all three jobs restore from the
same cache entry. Only the job whose Node version matches the cached
binary passes. The other two fail.

This explains the timing: failures started ~May 19 after the
`setup-node` v4→v6 and `pnpm/action-setup` v4→v6 dependabot bumps (May
15, PRs #4857/#4858) reset the cold cache. The first warm run after that
was broken for whichever two Node versions didn't win the write race.

This is a [known upstream bug in
setup-node](actions/setup-node#1171) (issue
#1171, fix pending in PR #1172, not yet in any release).

### Fix

Replace `cache: "pnpm"` in `setup-node` with a manual `actions/cache`
step that scopes the key to the Node.js version:

```
key: ${{ runner.os }}-pnpm-store-${{ matrix.node-version }}-${{ hashFiles('pnpm-lock.yaml') }}
```

Each Node version now has its own isolated pnpm store cache entry. An
ABI-137 binary cached by a Node 24 job can never be served to a Node 20
or 22 job.

The step uses `$GITHUB_OUTPUT` (scoped step output) instead of
`$GITHUB_ENV` per GitHub's security hardening guide.

## Test plan

### Local reproduction (primary evidence)

`better-sqlite3` uses classic ABI (`NODE_MODULE_INIT`, not N-API), so
its binaries are Node-version-specific. With a Node 24 binary in place,
switching to Node 22 without reinstalling reproduces the exact CI
failure:

```
# Binary compiled under Node 24 (ABI 137) — works fine:
$ node --version && node -e "new (require('better-sqlite3'))(':memory:').prepare('SELECT 1').get()"
v24.5.0
{ '1': 1 }

# Same binary, switched to Node 22 (ABI 127) without reinstalling — fails:
$ node-22 -e "new (require('better-sqlite3'))(':memory:')"
Error: The module was compiled against a different Node.js version using
NODE_MODULE_VERSION 137. This version of Node.js requires NODE_MODULE_VERSION 127.
Please try re-compiling or re-installing the module.
```

This is exactly what the shared cache was doing to Node 20/22 jobs:
handing them a binary compiled for a different ABI.

### CI validation

Two runs on this PR confirm the fix end-to-end:

1. **Cold-cache run**
([26185670340](https://github.com/CopilotKit/CopilotKit/actions/runs/26185670340)):
all three jobs install fresh, each writes its own per-version cache
entry, all pass.

2. **Warm-cache run**
([26187495270](https://github.com/CopilotKit/CopilotKit/actions/runs/26187495270)):
each job restores from its own per-version cache entry — the exact
scenario that was previously broken. All pass, with install times
dropping from ~22s (cold, downloading) to 7–10s (warm, linking from
store), confirming real cache hits were served.

| Job | Result | Cache restore | Install |
|-----|--------|--------------|---------|
| unit (20.x) | ✅ pass | 12s (hit) | 8s |
| unit (22.x) | ✅ pass | 12s (hit) | 7s |
| unit (24.x) | ✅ pass | 14s (hit) | 10s |

…ABI mismatch

The pnpm store cache key used by setup-node does not include the Node.js
version, so a cache entry written by a Node 24 job contains an ABI-137
better-sqlite3 binary. When Node 20 (ABI 115) or Node 22 (ABI 127) jobs
restore from the same cache key they get the wrong binary and all
sqlite-runner tests fail with "Module did not self-register".

Adding `pnpm rebuild better-sqlite3` after install re-runs prebuild-install
for the active Node version, downloading the correct prebuilt binary and
overwriting whatever ABI was in the restored cache.

Root cause first appeared after the setup-node v4→v6 and pnpm/action-setup
v4→v6 bumps (May 15, PRs CopilotKit#4857/CopilotKit#4858) reset the cold cache, allowing a
Node 24 binary to poison the shared store entry.