Add an isolated Kotlin Multiplatform foundation

[kunal26das]

Summary

Architectural discussion: Discussion #1020 is the current venue for evaluating architectural fit and downstream costs. This fork stack is an experimental implementation reference; upstream KMP integration is awaiting architectural agreement.

Introduce a standalone Kotlin Multiplatform build as the foundation of a series evaluating shared Android/iOS library code in React Native. The intended consumers are small native utilities whose decisions are currently implemented separately in Kotlin and Objective-C. Native views and rendering remain platform-owned; there is no Compose dependency.

This native fork PR mirrors the upstream KMP foundation submission as layer 1 of six. The registered fork stack uses dependent PR bases, so this PR shows its incremental diff.

Stack order: Foundation → RNTester dependencies → Gradients → Native multipart bounds → Shared multipart parsing → Scroll offsets.

This mirror retains the exact validated source of the upstream submission. The results below keep their original scope and provenance; restacking is not a new test run.

This base PR establishes the compiler and interop test surface only: JVM, iOS device ARM64, Apple Silicon simulator and Intel simulator targets; pinned Gradle/Kotlin tooling; and a dedicated CI workflow. It adds 14 files and does not connect the module to React Native applications or published artifacts. A test-only arithmetic fixture is enabled explicitly and produces separate artifacts, so it introduces no production API.

The first use case is gradient stop calculations in upstream #58456. Multipart framing upstream #58474 and explicit scroll snap-target selection upstream #58475 are separate dependent proposals. Each use case must justify its own shared boundary, parity coverage and costs.

Why evaluate KMP here?

The candidate Android consumers are already Kotlin. Sharing pure Kotlin could let both platforms use the same implementation and common tests without introducing an Android JNI interface for each utility. That benefit must be weighed against Kotlin/Native's runtime, build, packaging and interop costs. React Native already has a substantial shared C++ foundation, which remains a strong alternative. Algorithms already shared in C++ are excluded from this series.

This PR establishes feasibility of the toolchain, not approval of production adoption. Existing gradient probes measured higher adapter latency and memory/binary costs; those results remain part of the gradient review.

Changelog:

[INTERNAL] [ADDED] - Add an isolated Kotlin Multiplatform build and compiler interop smoke tests.

Test Plan

From packages/react-native/ReactShared, with JDK 17 and Xcode 26.6 locally:

./gradlew -PreactNativeSharedSmoke=true jvmTest iosSimulatorArm64Test \
  linkDebugFrameworkIosArm64 linkReleaseFrameworkIosArm64 \
  linkDebugFrameworkIosSimulatorArm64 linkReleaseFrameworkIosSimulatorArm64 \
  linkDebugFrameworkIosX64 linkReleaseFrameworkIosX64 --max-workers=2 --console=plain
./scripts/test-apple-smoke.sh
./gradlew jvmJar

• Four common tests passed on each of JVM and ARM64 iOS simulator; zero failures/skips.
• All six Debug/Release frameworks built with their expected architectures.
• Five Objective-C interop cases passed in each of Debug and Release.
• Default JAR contains no classes; the smoke fixture appears only in its opt-in output.
• Wrapper checksum, shell syntax, formatting, and the workflow's nonempty-test assertions checked.

Intel simulator execution is deferred; physical devices were not tested. No application adoption is included in this base PR, so the checks above do not claim application integration or acceptable runtime performance.