feat(android): add biometrics support for Android emulators

[limpbrains]

Description

• This pull request addresses the issue described here: Support Biomatetrics enrollment on Android #3198

In this pull request, I have added Android emulator support for Detox's biometrics API. Existing iOS
behavior is unchanged. Reviewed and tested end-to-end on a real emulator before submission.

• device.setBiometricEnrollment(bool) and device.matchFinger() / unmatchFinger() now work on
  Android emulators (AVDs), using the Virtual Fingerprint HAL.
• device.matchFace() / unmatchFace() work on Android emulators via the Virtual Face HAL, opt-in
  with setBiometricEnrollment(true, { androidFace: true }). The face path reboots the emulator on
  first activation (~20s); subsequent calls short-circuit (~3s).
• Attached devices and Genymotion Cloud throw clear "only supported on Android emulators (AVDs)"
  errors with actionable hints.
• Requires a userdebug AVD (standard Android Studio images).

Test plan

• Unit: 3217 tests pass; new coverage across ADB.test.js, AndroidDriver.test.js, new EmulatorDriver.test.js, RuntimeDevice.test.js.
• E2E: 8/8 pass on a real Pixel 3a API 34 userdebug AVD (detox/test/e2e/14.android-biometrics.test.js), covering both fingerprint and face paths including idempotent re-enable.
• Backwards compatible — existing setBiometricEnrollment(bool) callers and all iOS behavior unchanged.

---

• I have added/updated the relevant references in the documentation files — docs/api/device.md.

• I have made the necessary changes in the types index file — detox/detox.d.ts (new BiometricEnrollmentOptions type + refreshed JSDoc; detox/index.d.ts is a pass-through wrapper so no direct edit was needed).

---

Code developed by Claude

[limpbrains]

Questions for maintainers

A few design decisions I'd like to double-check before merging — happy to revise any of these:

1. AVD-only scope. Physical devices and Genymotion Cloud throw "only supported on Android emulators (AVDs)". This is because the Virtual Fingerprint / Face HAL and adb emu finger console commands don't exist on real devices, and Genycloud's adb tunnel doesn't reliably pass through them either. Is AVD-only the right scope, or is there a real-device path (e.g., via cmd fingerprint enroll on rooted Android) you'd want supported too?

2. { androidFace: true } option name. I chose an explicit Android-prefixed flag to make the reboot cost and platform scope obvious at the call site. Would you prefer something more neutral like { modality: 'face' } (ignored on iOS since iOS enrolls both), or the current Android-scoped shape?

3. Face HAL reboot + launchApp requirement. The first-time face enable on a fresh AVD reboots the emulator (Virtual Face HAL needs the feature flag + secure setting + sensor props applied before boot). The user must call device.launchApp({ newInstance: true }) afterward. Subsequent calls short-circuit. Is this UX acceptable, or would you want EmulatorDriver to re-launch the app transparently?

4. device_config set_sync_disabled_for_tests persistent. Needed so the face feature flag survives the reboot. It's a global AVD-state mutation that setBiometricEnrollment(false, {androidFace: true}) doesn't revert — documented in docs/api/device.md. Should the disable path reset it, or is the documented caveat enough?

5. Test-app UI coverage. The e2e tests validate the Detox-API layer only (commands issue successfully, errors thrown where expected). There's no native BiometricPrompt screen in detox/test to verify app-observable effects. Would you like that added in this PR, or is it a reasonable follow-up?

cc @noomorph