chore: automate RN release with prepare and publish workflows

[joaodordio]

Summary

Add two workflows to align the RN release process with the automations in swift-sdk and iterable-android-sdk. Today RN still relies on the manual scripts/release_next_version.sh flow which runs npm publish off a laptop.

• prepare-release.yml (workflow_dispatch): takes version plus optional ios_sdk_version, android_sdk_version, jira_ticket, and docs_pr_url. It bumps package.json, regenerates src/itblBuildInfo.ts, optionally bumps the pinned Iterable iOS and Android SDK versions in Iterable-React-Native-SDK.podspec and android/build.gradle, promotes the ## [Unreleased] block in CHANGELOG.md to ## X.Y.Z, and opens a release-labeled PR via peter-evans/create-pull-request.
• release.yml (workflow_dispatch): takes version, branch (default master), and set_prerelease. Verifies package.json and src/itblBuildInfo.ts match, extracts the changelog section for that version, tags the branch, creates the GitHub Release, and runs npm publish --provenance --access public (matches iterable-web-sdk).

Also adds a ## [Unreleased] marker at the top of CHANGELOG.md. Contributors accumulate entries under it going forward and the prepare workflow promotes them at release time. Older ## X.Y.Z entries left untouched, and validate-release.yml needs no changes because the workflow writes ## X.Y.Z (no brackets) which matches its existing grep -qF "## $version" check.

Why this shape

• Mirrors iOS/Android so the release ergonomics are consistent across the mobile SDKs. Same "prepare PR → merge → run release workflow" flow.
• Removes laptop-based npm publish. All auth lives in a GitHub Environment.
• Keeps Validate Release PR in charge. The generated PR is validated by the same rules as manual ones (docs PR link, changelog entry, itblBuildInfo.ts consistency).
• Optional native pin bumps. The two most common release triggers (bumping iOS-SDK or Android-SDK deps) become one-line workflow inputs instead of a PR authored by hand.

Setup required before first run

1. GitHub Environment npm needs to exist on this repo. Either add NPM_TOKEN as a secret, or configure npm Trusted Publisher for @iterable/react-native-sdk. This matches the setup in iterable-web-sdk. Without provenance, drop --provenance from release.yml.
2. Downstream workflow triggering: the prepare workflow uses secrets.GITHUB_TOKEN, so Validate Release PR and CI won't fire on the PR until the release manager edits the body or pushes an empty commit. Same limitation as iOS/Android today. Followup will swap this to SDK_RELEASE_TOKEN (already exists in iOS) or a GitHub App across all four SDK repos in one pass.

Verification

• Awk logic simulated against a fixture with mixed bracketed/legacy version headers. Prepare-side promotion produces the expected new ## X.Y.Z block; release-side extraction pulls the exact promoted section.
• Sed patterns verified against the real Iterable-React-Native-SDK.podspec (Iterable-iOS-SDK 6.6.7 → 6.6.8) and android/build.gradle (com.iterable:iterableapi 3.6.2 → 3.6.3).
• Node/yarn setup uses .nvmrc (v22.14.0) and the repo-pinned yarn 3.6.1 via yarnPath. yarn install --immutable picks the right binary.

Test plan

• Merge, then run Prepare Release on master with a throwaway version (e.g. 9.9.9-test) to inspect the generated PR diff.
• On the generated PR, add an entry to CHANGELOG.md ## [Unreleased] beforehand to confirm promotion works, and rerun.
• Once the npm environment is set up, run React Native SDK Release against a -beta1 version end-to-end.

Not touched

• scripts/release_next_version.sh and the release-it config in package.json remain as a manual escape hatch. Retire once the automation ships one or two releases cleanly.
• README.md version compatibility table is intentionally left to human edit in the release PR (native pins are optional and diverging them automatically is risky). Called out in the generated PR checklist.

[github-actions]

Lines	Statements	Branches	Functions
	71.92% (579/805)	61.22% (229/374)	67.18% (174/259)

[qltysh]

Coverage Impact

This PR will not change total coverage.

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.