Fail the build when the packaged binding does not match the package version

[iampawan]

Fixes #68.

The problem

postbuild copies nodejs/lib/binding/node_setapp_binding.node into nodejs/dist/lib/binding/, and nodejs/dist is what main loads. That source directory is gitignored, so on a machine where node-gyp has not run for the current version it holds a binding left over from an earlier one — and the copy succeeds silently.

Because the binding statically links the Swift library, the version it was built against is the version consumers actually run, whatever package.json says. Nothing downstream can detect or correct it.

The published packages show the effect (versions and stamps taken straight from npm):

package	libSetapp.a	published binding
5.3.0	5.3.0	5.2.1
5.3.1	5.3.1	5.2.1
5.3.2	5.3.2	5.2.1
5.3.3	5.3.3	5.2.1

The full table in #68 goes back to 4.3.4; 5.1.0 appears to be the only release where the two matched.

The change

One check appended to postbuild, comparing the copied binary's embedded __scv__ stamp with the package version, failing the build on a mismatch.

"postbuild": "... && node ./scripts/check-binding-version.js"

scripts/ is outside the tsconfig include ("nodejs") and outside the published files list, so it is neither compiled nor shipped.

Verified

Run against real binaries on macOS 26.5 / Node 24:

input	result
the published 5.3.3 binding (built against 5.2.1)	exit 1, names both versions
a 5.3.3 binding built from this repo at the 5.3.3 tag	exit 0
binding missing	exit 1
file present but carrying no stamp	exit 1

The failure output:

[check-binding-version] the binding is built against Setapp 5.2.1, but this package is 5.3.3.

  nodejs/dist/lib/binding/node_setapp_binding.node

Publishing this would ship a library 5.2.1 runtime as 5.3.3: the
binding statically links the Swift library, so its version is what consumers run,
and any API added since 5.2.1 would be missing with no way to detect it.

Rebuild the native binding for this version, then run the build again:
  npx node-gyp rebuild && npm run build

Notes

• This is intentionally a guard, not an automatic rebuild. Adding node-gyp rebuild to build would change how release artifacts are produced, which is your call to make; a check that refuses the wrong binary is safe either way. Happy to switch it to a warning if you would rather not fail the build.
• It does not fix the already-published packages — those need a republish with a rebuilt binding.
• It also does not address the second half of npm package ships an N-API binding built against an older Setapp library (5.3.3 ships 5.2.1) #68: a binding built from this repo carries the correct library but does not complete the provisioning handshake for us, while the published one does. We could not work out why, and would value a pointer.