Add ability for mobile to send and receive queries from native host

[EimantasMorkunas]

Add APIs for passing queries between backend JS and host:

• Add sendQueryToNative() to MobileDevice that allows sending queries from JS backend.
• Add handleNativeQuery() to MobileDevice that gets invoked when the host sends a query. Handling can be overridden by setting MobileHost.nativeQueryHandler. It throws by default which responds to all queries with an error.

imodel-native-internal: https://github.com/iTwin/imodel-native-internal/pull/1180

[tcobbs-bentley]

Follow-Up: Where to Run the Mobile Bridge Tests in CI

Recommendation: use display-test-app (DTA) as the shared native integration-test host, with a dedicated bridge-test mode rather than extending the model-download/render sequence. This reuses the existing Android Emulator and iOS Simulator jobs without making messaging tests depend on authentication, downloads, or rendering. Keep pure handler-forwarding tests in core-mobile with ordinary Node/Mocha execution.

The locations below were inspected in the local checkouts during the CI follow-up; unlike the original review comments, they are not all pinned to the PR heads.

Concrete Insertion Points

• Backend test coordinator: MobileMain.ts. Register the query handler before startup and run tests after initializeDtaBackend completes. That initialization already calls MobileHost.startup.
• Android native counterpart: MainActivity.kt. Register the native query callback before startup and initiate native-to-backend queries once backend readiness is established.
• iOS native counterpart: ViewController.swift. Register the native callback before loading the backend and use its readiness callback to initiate queries.
• CI result handling: runAndroidEmulator.py and runIosSimulator.mjs. Both currently accept "First render finished." as success. Bridge-test mode needs its own completion result, failure reporting, and timeout.

Dedicated Bridge-Test Mode

1. Initialize the backend without creating or loading a WebView, and skip model configuration/download checks in the runners for this mode.
2. Exercise both query directions, asynchronous responses, missing handlers, rejection handling, and duplicate/concurrent native replies.
3. Emit a distinct success marker only after all assertions finish. Explicit assertion failures, crashes, and timeouts must fail CI. Android's existing retry must not turn an observed assertion failure into a pass.
4. Keep the existing model-download/render smoke test as a separate mode, so its success marker cannot mask bridge-test failures.

Running without a WebView establishes independence from frontend execution. It does not establish actual OS background behavior; retain a separate app-backgrounding scenario under the app-integration assumptions above. All test initiation, coordination, and completion reporting for that scenario must remain native/backend-driven rather than depending on frontend JavaScript.

Why Not Add These Directly to Backend Unit Tests?

The existing iOS harness is reusable infrastructure, but not a drop-in home for tests that start MobileHost:

• core/backend/package.json bundles only backend tests. Adding tests to core-mobile would not automatically include them in this simulator job; core-mobile currently has no test directory and its test/cover scripts are empty.
• The native test runner treats the backend-ready callback as test completion.
• runMocha.js calls notifyListening(numFailed) on process exit. In contrast, MobileRpcServer.ts calls that binding for server readiness. Starting MobileHost in the existing harness would mix the two protocols and could report readiness as completion. The live mobile server also requires an explicit shutdown/completion strategy rather than simply waiting for process exit.
• No equivalent Android unit-test host was found in the paths examined. DTA already provides a native app and emulator launcher for Android.

A shared mobile test runner would be cleaner longer term, but it requires more infrastructure. A dedicated DTA mode is the smallest shared integration-test solution for these PRs. Avoid putting mobile bridge tests into core-backend just to reach its iOS runner; the test ownership belongs with core-mobile and the native host integration.

CI Enablement Gate

At the reviewed native PR revision, build_itwinjs-core.yml does not pass buildMobile: true to the core template in the Build darwin-arm64 iTwinjs-core job. The core template defaults that parameter to false, and the Android DTA, iOS DTA, and iOS backend Simulator steps all require it. Core fast CI explicitly enables it.

The native macOS job must therefore enable that parameter before these tests will run through this template path. This finding was checked against native PR head db7183a760de4f43a7128bdb6ad05ac8753acaf5 and the local core template, not against a live pipeline run. If the actual pipeline consumes another core-template revision, verify that revision's parameter behavior as well.

This follow-up is a source/YAML investigation only. No runner, app, pipeline, or test implementation was changed, and no simulator/emulator execution was performed.