CI: fast package-lint job (publint + attw + tarball-contents assertion)

[gmaclennan]

Problem

The example app consumes the module via a Metro alias to the repo root (apps/example/metro.config.js → @comapeo/core-react-native: '../..'), and all existing CI consumes the workspace source, never the packed tarball. Nothing today catches a missing files entry, an unbuilt native artifact, or a broken exports map — the classic "works locally, broken on npm" failure.

This module is especially exposed because most of what ships is generated and gitignored: android/src/main/jniLibs/**/*.so, android/src/main/assets/nodejs-project/, ios/Frameworks/**.xcframework, ios/nodejs-project/, android/libnode/, and build/. A regression in the files array or a platform-gated build step (e.g. publishing from Linux → empty ios/Frameworks/) would pass all current tests and produce a runtime-broken package.

Proposed: fast PR-level package-lint job

Cheap checks that run on every PR (seconds, reuse existing download:nodejs-mobile + backend:build steps on a macOS runner):

• publint — validates exports/main/types resolution.
• @arethetypeswrong/cli — catches ESM/CJS + types mismatches across the . and ./sentry export conditions.
• Tarball-contents assertion — npm pack --json, then assert the tarball contains at least one android/src/main/jniLibs/**/*.so, one ios/Frameworks/**.xcframework, the Android + iOS nodejs-project bundles, android/libnode/bin/**/libnode.so, and build/index.js. This is the highest value-per-second check and would have caught a Linux-published (iOS-less) tarball.

Context

Spun off from the release workflow PR (.github/workflows/release.yml). See the build pipeline in scripts/build-backend.ts and the files array in package.json.