Harden the host's resolution heuristics: addon detection and Xcode workspace lookup

[kraenhansen]

Two places in the host CLI where a shortcut stands in for a proper check. Both fail quietly or unhelpfully rather than loudly.

isNodeApiModule treats any .node file as an addon

react-native-node-api/packages/host/src/node/path-utils.ts

Lines 64 to 78 in 29a527d

	* @returns True if a platform specific prebuild exists for the module path, warns on unreadable modules.
	* @throws If the parent directory cannot be read, or if a detected module is unreadable.
	* TODO: Consider checking for a specific platform extension.
	*/
	export function isNodeApiModule(modulePath: string): boolean {
	{
	// HACK: Take a shortcut (if applicable): existing `.node` files are addons
	try {
	fs.accessSync(
	modulePath.endsWith(".node") ? modulePath : `${modulePath}.node`,
	);
	return true;
	} catch {
	// intentionally left empty
	}

The HACK short-circuits: if <path>.node exists, it returns true without ever checking that it is one of ours. But PLATFORM_EXTENSIONS is specific — .android.node and .apple.node — and a plain .node file is exactly what a Node.js-targeted addon (or a leftover node-gyp build output in build/Release/) looks like. Accepting it means auto-linking picks up something it cannot load, and the failure surfaces later and further away, at runtime on device.

The accompanying TODO on the doc comment asks for the same thing: check for a specific platform extension. Worth doing together, since the fast path exists to avoid the batch directory scan and any fix needs to preserve that.

While in this file: the TODO: Change to .apple.node above PLATFORMS (line 11) is stale — PLATFORM_EXTENSIONS.apple is already ".apple.node" two lines below. It can just be deleted.

findXcodeWorkspace gives up instead of walking upwards

react-native-node-api/packages/host/src/node/cli/xcode-helpers.ts

Lines 56 to 69 in 29a527d

	// Check if the directory contains an "ios" or a "macos" directory and call recursively from that
	const iosDirectory = path.join(fromPath, "ios");
	if (fs.existsSync(iosDirectory)) {
	return findXcodeWorkspace(iosDirectory);
	}
	const macosDirectory = path.join(fromPath, "macos");
	if (fs.existsSync(macosDirectory)) {
	return findXcodeWorkspace(macosDirectory);
	}
	// TODO: Consider continuing searching in parent directories
	throw new Error(`No Xcode workspace found in '${fromPath}'`);
	}

The search descends into ios/macos from the starting directory and otherwise throws. Running the command from anywhere below the app root — src/, or a package directory in a monorepo, which is the normal place to be standing — fails with No Xcode workspace found in '<cwd>' even though the workspace is one level up. Walking up to the repository/package root before giving up (bounded, e.g. stopping at a .git or the filesystem root) would match what every other RN tool does.