Use CMake file API to read shared library target paths

[kraenhansen]

This PR is stacked on #257 and fixes #253 by introducing use of the CMake file API to read shared library target paths.

Merging this PR will:

• Implement at wrapper around the CMake file API to query and read metadata for targets in the build directories, instead of relying on pre-defined locations.
• Fix cmake-rn fails if projects emit more than one dynamic library #201 by leaning on the CMake structure to group shared library artifacts.

---

Note

Switches artifact discovery to the CMake File API and updates Android/Apple post-build flows and host helpers to assemble outputs per-target using the new APIs.

• cmake-rn:
  • Use cmake-file-api: add dependency and initialize query (codemodel v2) in src/cli.ts.
  • Android postBuild: read targets via CMake File API, group shared libraries by target, and assemble per-library .android.node outputs using updated host API; include configuration.
  • Apple postBuild: read targets via CMake File API, generate frameworks and assemble per-library XCFrameworks (or .apple.node).
• host (prebuild helpers):
  • Android: change createAndroidLibsDirectory signature to libraries: { triplet, libraryPath }[]; adjust implementation.
  • Apple: make createAppleFramework async and use spawn/fs.promises.
• ferric:
  • Adapt to new Android helper signature and await async createAppleFramework when building XCFrameworks.

^{Written by Cursor Bugbot for commit 4d0b7df. This will update automatically on new commits. Configure here.}

[Copilot]

Pull Request Overview

This PR implements CMake file API integration to dynamically read shared library target paths instead of relying on pre-defined directory locations. This fixes issue #253 by introducing a wrapper around the CMake file API to query and read metadata for targets in build directories.

• Adds a new cmake-file-api.ts module with comprehensive Zod schemas for parsing CMake file API responses
• Updates both Apple and Android platform implementations to use the file API for discovering shared library artifacts
• Replaces hardcoded file discovery logic with dynamic target querying based on CMake metadata

Reviewed Changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/cmake-rn/src/cmake-file-api.ts	New module implementing CMake file API wrapper with Zod schemas and query/parsing functions
packages/cmake-rn/src/cmake-file-api.test.ts	Unit tests for the file API functionality, specifically testing reply index path resolution
packages/cmake-rn/src/platforms/apple.ts	Updated to use CMake file API instead of directory scanning for shared library discovery
packages/cmake-rn/src/platforms/android.ts	Updated to use CMake file API instead of directory scanning for shared library discovery
packages/cmake-rn/src/cli.ts	Added query creation for codemodel-v2 API during project configuration
packages/cmake-rn/package.json	Added zod dependency for schema validation
.changeset/evil-vans-love.md	Changeset documenting the patch-level change

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Pull Request Overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[matthargett]

Can you cover a few more exceptional cases to make sure there's feedback up to the CLI with actionable output? A couple of cases

• Write an index-v2.json with an unknown version string → assert unsupported-version error
• Drop in a malformed JSON (missing artifacts or targetName) in either index or reply → assert a JSON-parse exception.
• a buildDir with unreadable permissions (common with sloppy sudo usage)

I'm okay to save these for a separate PR but before tagging a release. I'm mostly thinking about support load :)

[kraenhansen]

I've pushed a commit removing a lot of the schema code I already added.

Instead, I'm going to use CoPilot to generate a wrapper around the CMake file API from their docs, as a separate package, similar to https://crates.io/crates/cmake-file-api for Rust. This will hopefully host a much more comprehensive test suite. That being said, we want to test our implementation of the specification, not CMake.

[kraenhansen]

I've opened #257 now and rebased this PR on top of that.

[Copilot]

Pull Request Overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated 1 comment.

[Copilot]

The TODO comment indicates this synchronous call should be made async, but the function has already been converted to async. Consider using cp.spawn with promises or a promisified version to maintain consistency with the rest of the async operations.

Suggested change

	// TODO: Make this call async
	cp.spawnSync("install_name_tool", [
	// Make this call async
	await spawn("install_name_tool", [