RFC: replace abandoned jsc-android with a maintained JSC (Bun's WebKit fork) on Android

## Problem

Android JSC support in JsRuntimeHost rides on [`jsc-android`](https://github.com/react-native-community/jsc-android-buildscripts) (`org.webkit:android-jsc`), which is effectively abandoned:

- The build we consume (`250231.x` / `250230.x`) is **WebKit SVN r250230, dated 2019‑09‑23** — a ~6‑year‑old JSC.
- Last npm publish was ~2 years ago. React Native moved its default engine to Hermes and, as of RN 0.79, split JSC into a separate package — the original `react-native-community/jsc-android-buildscripts` is dormant.
- No active maintainer, corporate sponsor, or community is shipping updates.

**Concrete impact, hit during the N‑API v7 work** (#185 / the v7 track): this JSC has **no BigInt** — its parser rejects `0n` literals outright — so JSC can't reach N‑API v6/v7 or JS‑language parity with V8 on Android. We had to feature‑detect‑fail BigInt (`ENOTSUP`) on Android‑JSC. Every future JS/N‑API feature gap repeats this.

## Proposal

Adopt a **modern, actively‑maintained JSC** on Android and retire the 2019 `jsc-android`.

Primary candidate: **Bun's JSC** — Bun tracks a current JavaScriptCore via its [`oven-sh/WebKit`](https://github.com/oven-sh/WebKit) fork and release‑builds it continuously, so it stays current on language + JSC C API surface. bun already builds an N-API compatible runtime on top of this JSC, so it would seem to serve our purposes very well.

possible caveat: Bun has an _old_ issue that declined first‑party Android support, and `oven-sh/WebKit` officially targets macOS/Linux/Windows. But their releases post Android aarch64/x64 build artifacts, and its demonstrably cross‑compilable to Android aarch64 as the community has proven: [`opencode-termux`](https://github.com/guysoft/opencode-termux) project cross‑compiles Bun + WebKit/JSC for Android (ICU 75.1 + WebKit/JSC aarch64) and enumerates the patch set required (Bionic stubs, TLS alignment, `if(ANDROID)` guards). So the work is: try and use `oven-sh/WebKit`'s prebuilt JSC for our Android ABIs and package it as a drop‑in `jsc-android` replacement exposing the same C APIs JsRuntimeHost already targets. if we want to slim down the binary size with variants (noJIT / no-intl), then we'd need to produce separate builds (or upstream a change to bun so they publish those variants .

Alternative I evaluated first: **[`@react-native-community/javascriptcore`](https://www.npmjs.com/package/@react-native-community/javascriptcore)** — the JSC package RN 0.79+ split out. I submitted a PR to update JSC (using bun's fork) and had intermittent contact with the maintainer who has since gone silent. We could fork jsc-android-buildscripts and publish to a different namespace, but I personally feel like there's more value/uplift to the global JS community by pitching in with Bun directly.

## Why this unblocks us

- N‑API v6/v7+ parity between JSC and V8 on Android (BigInt, and whatever's next).
- JS language‑feature parity — removes the "works on V8, throws on Android/Linux JSC" cliff. (and macOS < 15)
- A publishing channel that's actually maintained, so we're not permanently pinned to 2019.

## Open questions / scope

- **C‑API surface**: I confirmed `oven-sh/WebKit` exposes the JSC C API (`JSContextRef`, `JSValueRef`, `JSObjectRef`, and the BigInt C API) we compile against.
- **ABI coverage**: `arm64-v8a` (+ `x86_64` for emulators); binary size vs `jsc-android`. It all looks like it's there in Bun's github releases, but we need to test integration
- **Build/CI**: Bun ships a .zip of the .a files, not an AAR . still, the Android patch set the community already mapped this out ahead of us, packaging likely uses FetchContent/prebuilt and we don't need to (cache) build from source.
- **Validation**: run the N‑API conformance suite (#116) — `test_bigint` should pass for real on Android‑JSC instead of the `ENOTSUP` fallback and no JS polyfill eval in the loop slowing things down.

Surfaced from the N‑API track: #116, #183, #185.