chore: add prepack script mirroring prepare (SDK-763)

[brax10ward]

Linear Link

SDK-763

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactor (non-breaking change which cleans up code)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• This change impacts security

Summary

Adds a prepack script to package.json that mirrors the existing prepare script (bob build && cp package.json lib/package.json). Unblocks consumers who install this repo as a git dep via Yarn 4 (e.g. github:atomicfi/atomic-transact-react-native#master), whose current install produces a package with no lib/ because Yarn 4's git-dep prep runs yarn pack → prepack, not prepare.

Yarn 4's git-dep preparation pipeline clones the repo, runs yarn install in it, then runs yarn pack to produce a virtual tarball. yarn pack executes the prepack lifecycle hook — not prepare. Because our package.json only defined prepare, nothing built lib/ during that pipeline, so the resulting tarball respected our files allowlist but shipped without the compiled output. main/exports in the SDK point at lib/commonjs/index.js, so downstream consumers resolving via those fields (Node, Jest, tooling, and modern Metro with package-exports enabled) failed to load the SDK.

Adding prepack alongside prepare (keeping both) means:

• Local yarn install in this repo still runs prepare — dev flow unchanged.
• npm publish still runs prepare — published tarballs unchanged.
• yarn pack (including inside Yarn 4's git-dep prep pipeline) now runs prepack — downstream git-dep consumers get a working install.

Verified

Before this change:

git clone --depth 1 --branch master ...
cd atomic-transact-react-native && yarn install && yarn pack
tar tzf package.tgz | grep -c lib/    # → 0

After this change:

tar tzf package.tgz | grep -c lib/    # → 53

Checklist:

• New and existing tests pass locally with my changes
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have tested on a physical iOS device and Android device
• I have added tests that prove my fix is effective or that my feature works
• I have followed the Code Review and Code Review Security guidelines
• I have checked my code against flaws from the OWASP Top 10
  • A01:2021-Broken Access Control
  • A02:2021-Cryptographic Failures
  • A03:2021-Injection
  • A04:2021-Insecure Design
  • A05:2021-Security Misconfiguration
  • A06:2021-Vulnerable and Outdated Components
  • A07:2021-Identification and Authentication Failures
  • A08:2021-Software and Data Integrity Failures
  • A09:2021-Security Logging and Monitoring Failures
  • A10:2021-Server-Side Request Forgery