Project-local CLI/SDK install dies with Failed to load native binding (auth binding skew) #718

Summary

Every project-local npm install of the CLI or SDK dies at startup with Failed to load native binding for <platform> (reproduced on 5/5 surfaces in the 2026-07-17 skilltester run). rc.2 GA blocker B1.

Root cause

@cipherstash/auth pins its six platform bindings as exact-version optional peerDependencies. Our catalog compensates by declaring the bindings in stack/stash/wizard's own optionalDependencies — but Dependabot bumped those six entries to 0.42.0 while @cipherstash/auth itself, individually ignored in dependabot.yml, stayed 0.41.0. With the set skewed, npm nests per-consumer binding copies (node_modules/stash/node_modules/@cipherstash/auth-darwin-arm64) that the hoisted auth package can never resolve.

Reproduction

npm i @cipherstash/stack@1.0.0-rc.2 @cipherstash/stack-supabase@1.0.0-rc.2
npm i -D stash@1.0.0-rc.2
node -e "require('@cipherstash/auth')"   # fatal before, loads after

Expected

The seven @cipherstash/auth* catalog entries must move in lockstep so npm dedupes to a single hoisted, resolvable binding — with a guard so a partial bump can't recur.

Resolution

Fixed in #679 — all seven @cipherstash/auth* entries aligned to 0.42.0, @cipherstash/auth-* added to the Dependabot ignore list, and a supply-chain e2e asserting the seven entries share one version.

Upstream follow-up

Durable fix is for @cipherstash/auth to declare its bindings as its own optionalDependencies (napi-rs default), so consumers never pin them — as @cipherstash/profile and @cipherstash/protect-ffi already do. Tracked separately in cipherstash-suite; once shipped, the catalog binding entries here can be deleted.