fix(tests): set RNPUnitTests SDKROOT to macOS

[ronaldtse]

Summary

Sets SDKROOT = macosx on the RNPUnitTests target. The target was created with SDKROOT = iphoneos + SUPPORTED_PLATFORMS = macosx — an iOS-style config on a macOS-only target. Aligns them so xcodebuild -scheme RNP build doesn't get confused by the test target being in the build graph.

What this does NOT fix

The deeper issue preventing @testable import RNP from resolving is a module-name case collision:

• The RNP executable target emits its swiftmodule labeled "RNP"
• The SPM package Rnp (lowercase) emits Rnp.swiftmodule
• APFS is case-insensitive by default on macOS, so RNP.swiftmodule and Rnp.swiftmodule are the same file in the build products directory
• The Swift compiler sees them as the same module and emits cannot load module 'RNP' as 'Rnp'

I tried three additional fixes that all failed:

1. SWIFT_INCLUDE_PATHS = $(CONFIGURATION_TEMP_DIR)/RNP.build/Objects-normal/$(ARCHS) — points at where the executable's swiftmodule actually lives. Triggers the case-collision error.
2. DEFINES_MODULE = YES on the RNP executable — installs RNP.swiftmodule to $(BUILT_PRODUCTS_DIR), which collides with the existing Rnp.swiftmodule (from the SPM package) and breaks the main app build.
3. SWIFT_EMIT_MODULE_INTERFACE = YES + SWIFT_INSTALL_MODULE = YES on RNP — doesn't actually emit anything to $(BUILT_PRODUCTS_DIR).

Real fixes (deferred — none are autonomous)

1. Rename the executable target from RNP to e.g. RNPApp. This changes the module name to RNPApp, avoiding the case collision with Rnp. Bundle ID (com.rnpgp.RNPForMail) stays unchanged — that's a separate concept. Cost: 1-line change + the test target's @testable import RNP becomes @testable import RNPApp.
2. Rename the SPM package from Rnp to e.g. RnpBindings upstream in swift-rnp. Cost: upstream PR + Package.swift change + every import Rnp becomes import RnpBindings.
3. Move integration tests to the UI test target (Ribose containerUITests) which doesn't @testable import the app module — it uses accessibility APIs. Cost: rewrite the tests in UI-test style.
4. Build on a case-sensitive APFS volume. Cost: requires creating a separate volume for builds; intrusive.

Option 1 is the cleanest locally — single project change, no upstream coordination. Option 2 is more correct (the package name Rnp is the unusual one; SPM conventions favor camelCase like RnpKit or similar) but requires an upstream PR.

Verification

• Main app build (xcodebuild -scheme RNP build) — BUILD SUCCEEDED
• Test target build (xcodebuild -scheme RNP build-for-testing) — still fails with cannot load module 'RNP' as 'Rnp' (the case-collision issue, unaddressed here)

Why ship this anyway

The SDKROOT = macosx fix is correct on its own merits (the previous setting was outright wrong). It removes one source of confusion from the test-target setup so the next person debugging the case-collision issue doesn't also have to figure out why the test target thinks it's iOS.

Follow-ups

1. Pick one of options 1-4 above and land it. Recommend option 1 (rename executable target to RNPApp).
2. Once that lands, the integration tests from PR test(coordinator): integration tests with rnp fixtures + wire RNPUnitTests scheme #201 will compile and run.
3. Add RNPUnitTests to ci.yml so every PR runs them.