bdk-rn pins uniffi-bindgen-react-native to an exact version, blocking coexistence with other ubrn libraries (+ 1.0 not on npm)

## Summary

We maintain a separate React Native library ([`@bennyblader/ddk-rn`](https://github.com/bennyhodl/ddk-ffi)) that, like bdk-rn, is generated with **uniffi-bindgen-react-native** (ubrn). We want to use **bdk-rn for the wallet** and **ddk-rn for DLCs** in the same app, but hit three blockers. The core one is a hard version conflict between the two libraries' ubrn pods.

## 1. All bdk-rn releases pin `uniffi-bindgen-react-native` to an exact version, so two ubrn libraries can't coexist

`BdkRn.podspec` (and `package.json`) pin an **exact** ubrn version:

```ruby
# BdkRn.podspec — v1.0.0, v2.2.0-alpha.1, v3.0.0-rc.3 all identical:
s.dependency "uniffi-bindgen-react-native", "0.30.0-1"
```

Our ddk-rn is generated with a newer ubrn and pins `uniffi-bindgen-react-native "0.31.0-3"`. Since an app can only resolve **one** version of the `uniffi-bindgen-react-native` pod, CocoaPods fails:

```
[!] CocoaPods could not find compatible versions for pod "uniffi-bindgen-react-native":
- bdk-rn depends on uniffi-bindgen-react-native (= 0.30.0-1)
- DdkRn depends on uniffi-bindgen-react-native (= 0.31.0-3)
```

This makes bdk-rn incompatible with **any** other ubrn-generated RN library that isn't on the exact same ubrn version. The generated podspec pins `=` (exact) rather than a compatible range, which guarantees a clash the moment two ubrn libraries pick different ubrn releases.

**Requests (any one would help):**
- Publish bdk-rn builds generated against current ubrn (`0.31.x`), or
- Relax the generated dependency from `= 0.30.0-1` to a compatible range (e.g. `~> 0.31`), or
- Document the intended way for multiple ubrn libraries to share one ubrn runtime pod version in a single app.

## 2. bdk-rn 1.0.0+ is not published to npm

`npm view bdk-rn versions` → `["0.1.0","0.1.1","0.29.0","0.30.0"]` (dist-tag `latest` = `0.30.0`). The 1.0.0 / 2.x / 3.0-rc releases exist only as **GitHub release tarballs** (`bdk-rn-1.0.0.tgz`), so consumers can't `npm install bdk-rn@1` and are stuck on the old `0.30.0`. Publishing 1.0.0 to npm would unblock everyone off the pre-new-arch build.

## 3. bdk-rn 0.30.0 (the npm `latest`) fails to build on RN 0.75 new architecture

Because 1.0+ isn't on npm, `0.30.0` is what most people get — and it doesn't compile under the New Architecture. `BitcoinDevKit.swift` does `import bdkFFI`, but with **static pod linkage** (the default when `use_frameworks!` is off) under new-arch the vendored dynamic `bdkFFI.framework` module isn't placed on the Swift import path, so the whole file fails:

```
BitcoinDevKit.swift:22:25: error: cannot find 'ffi_bdk_bc5f_rustbuffer_from_bytes' in scope
BitcoinDevKit.swift:431:5: error: cannot find 'bdk_bc5f_Address_new' in scope
... (every bdk_bc5f_* / ffi_bdk_bc5f_* symbol)
```

(The `bdkFFI.xcframework` itself is complete — headers + `module.modulemap` are all present — it's purely a linkage/import-path issue under new-arch static linking.)

## Environment
- bdk-rn `0.30.0` (npm), and `1.0.0` / `3.0.0-rc.3` (GitHub) inspected
- React Native 0.75.5, New Architecture enabled (`RCT_NEW_ARCH_ENABLED=1`)
- Xcode 26.x, CocoaPods, iOS simulator
- Coexisting ubrn library: ddk-rn (ubrn `0.31.0-3`)

Happy to test any fix or provide a minimal repro. Thanks for the great work on bdk-rn 🙏

Start by comparing the pinned dependency in BdkRn.podspec and package.json with the versions in ddk-rn, then reproduce the CocoaPods conflict. Check the npm package versions and the BitcoinDevKit.swift import errors under React Native 0.75.5 with the New Architecture enabled. Done means one documented or verified path resolves the reported coexistence, publishing, or build problem.

Written by the indexing model from the issue text.