BLE: Keep hybrid direct-MX + MB test scaffolding as a low-cost re-validation path for future iOS releases

[dl-alexandre]

Summary

As part of the 2026-05 carrier decision work, MeshX introduced two durable instrumented test classes and supporting production hooks:

• IOSAuxFullMxAdvertSmokeTest (Android side emitter of hybrid MB cue + direct-MX service-data full envelope)
• IOSHybridDirectMxReceiveTest (Android side observer + correlation logic)

These tests, together with the iOS harness --meshx-auto-direct-mx-hybrid-advertise flag and the BleScanner / BleDispatcher hybrid correlation paths (recentMBBeacons, onDirectMxServiceDataWithMagicReceived, HYBRID_SUCCESS etc. markers), form a self-contained evidence bundle that can re-validate the direct carrier shape cheaply.

Current status

The direct carrier is rejected for production on current iOS stacks. The tests are intentionally kept (they assert the expected negative outcome for iOS while still exercising the correlation logic).

Request

Please treat the hybrid/MB+service-data scaffolding in the mob bridge (Android scanner/dispatcher + any corresponding iOS responder bits) as intentionally retained test / future-proofing code, not dead code to be removed.

When a future iOS release relaxes the foreground manufacturer-data or custom service-data restrictions, the same test pair + harness flags can be used for rapid positive validation without re-implementing the plumbing.

Cross-reference the two open PRs for the build side:

• [codex] Support project iOS Swift sources #6
• [codex] Compile project iOS Swift sources mob_new#5

The test surface is small, well-documented in the test Javadocs, and already wired into the release artifact bundle expectations.

This avoids a future "we threw away the direct path code" situation when the platform limitation eventually moves.

[dl-alexandre]

After reviewing MOB_PLUGINS.md and the plugin model in the mob docs, this issue is already well-aligned.

The hybrid MB + direct-MX test scaffolding (IOSAuxFullMxAdvertSmokeTest, IOSHybridDirectMxReceiveTest, the correlation logic in BleScanner/BleDispatcher, and the HYBRID_* markers) is exactly the kind of reusable validation harness that will be valuable when developing or evolving a BLE transport plugin for mob.

We are requesting that this code path and its test infrastructure be preserved as future-proofing, not because we expect direct-MX to become the default on current iOS, but because it gives the ecosystem (and any future iOS platform relaxation) a low-cost way to re-validate carrier shapes.

This fits cleanly with the plugin philosophy: keep the extension points and test surface that plugin authors will need.