Revert `android/CMakeLists.txt` workaround once uniffi-bindgen-react-native > `0.31.0-3` is released

`uniffi-bindgen-react-native@0.31.0-3` publishes an `exports` map that does not expose
`./package.json`:

```json
"exports": {
".": {
"types": "./typescript/dist/esm/index.d.ts",
"import": "./typescript/dist/esm/index.js",
"require": "./typescript/dist/cjs/index.js"
}
}
```

The generated `android/CMakeLists.txt` resolves the package root with:

```
node -p "require.resolve('uniffi-bindgen-react-native/package.json')"
```

which now throws `ERR_PACKAGE_PATH_NOT_EXPORTED`. The `execute_process` call has no
`RESULT_VARIABLE`, so CMake swallows the failure, `UNIFFI_BINDGEN_PATH` ends up empty,
and the compile line gets `-I/cpp/includes`. The build then fails with a misleading:

```
cpp/generated/bdk.hpp:5:10: fatal error: 'UniffiCallInvoker.h' file n
```

## Why we patched it here rather than in the dependency

Upstream already fixed this by adding `"./package.json": "./package.json"` to their
exports — jhugman/uniffi-bindgen-react-native#407, merged as `2b57645
**unreleased**. The latest published version is still 0.31.0-3.

Their CMakeLists template is byte-identical between 0.31.0-3 and `main`, so there is no
upstream template change to port.

A local patch of the dependency (e.g. `pnpm patch`) would fix our bui
users': we ship `android/CMakeLists.txt` inside the tarball and pin `0.31.0-3`, so every
downstream consumer resolves the unfixed package from their own `node
has to live in the file we publish.

Pinning the dependency to a git commit on `main` was also considered and rejected — it
fixes the library build but breaks consumer installs. pnpm 10 refuses
with a `prepare` script unless allowlisted in `pnpm-workspace.yaml`, and ubrn's `prepare`
is `yarn build`, so every consumer would need yarn on their machine.

## What we changed

Commit: `fix(android): work around unreleased ubrn package.json export` (f6afb0a8166da273b83907380f272355c5d77474)

- **`android/CMakeLists.txt`** — attempt the stock upstream resolutio
patch becomes a no-op as soon as they publish, and fall back to walking up from the
package entry point (which no `exports` map can gate) when the expo
Also added the `RESULT_VARIABLE` guard suggested in the upstream issue, so a failed
resolution aborts at configure time instead of resurfacing as a mis
- **`ubrn.config.yaml`** — added `noOverwrite: [android/CMakeLists.txt]`, because
`ubrn build android --and-generate` regenerates that file on every
otherwise wipe the patch.

## Exit criteria

When a `uniffi-bindgen-react-native` release after 0.31.0-3 is published:

1. Bump the dependency in `package.json` and the `s.dependency` version in `BdkRn.podspec`.
2. Confirm the new version exports `./package.json`:
`npm view uniffi-bindgen-react-native@ exports --json`
3. Revert the commit above (both files).
4. Run `just build-tarball-android`, confirm `android/CMakeLists.txt` regenerates cleanly
now that `noOverwrite` is gone.
5. Run `cd tests && just test` against an emulator to confirm the native build still links.

## Notes

- Upstream tracking issue: jhugman/uniffi-bindgen-react-native#421
- Unrelated to this workaround and **not** to be reverted: 0.31 moved
runtime to `@ubjs/core`, which the generated bindings now import, so it had to be added
to our `dependencies`. That change stays after the upgrade.

Wait for a uniffi-bindgen-react-native release after 0.31.0-3, then inspect package.json, BdkRn.podspec, android/CMakeLists.txt, and ubrn.config.yaml. Verify the release with npm view, revert commit f6afb0a8166da273b83907380f272355c5d77474, and run just build-tarball-android. Confirm regeneration is clean and run cd tests && just test against an emulator to verify the native build still links.

Written by the indexing model from the issue text.