fix: gate iOS geofence enablement on a dictionary config

[mrehan27]

Summary

Fixes the iOS-only inconsistency Bugbot flagged on #620.

The geofence enablement checks used key presence (config["geofence"] != nil), while the module builder NativeGeofence.module(from:) only builds the module for a dictionary value (config["geofence"] as? [String: Any]). So a non-map geofence value — e.g. null bridged from JS — would:

• register the implied Location module (NativeLocation.module(..., geofenceEnabled: true)), and
• default allowBackgroundDelivery on,

…without actually adding the geofence module.

Both checks now use the same as? [String: Any] cast. Normal cases (geofence: {}, { locationMode }, or absent) are unchanged; only a malformed/non-map value now correctly reads as not-configured.

Android already gates on getTypedValue<Map<String, Any>> for both the enable check and the module, so no change there.

---

Note

Low Risk
Narrow initialization guard change; only affects malformed/non-map geofence config, with normal dictionary or absent config unchanged.

Overview
Fixes inconsistent iOS geofence gating when geofence is present in init config but not a map (e.g. null from JS).

geofenceConfigured and geofenceAdded now use config["geofence"] as? [String: Any] != nil, matching NativeGeofence.module(from:). Previously, key presence alone could turn on implied Location registration and default allowBackgroundDelivery without actually adding the geofence module. Valid geofence objects and omitted config behave as before.

^{Reviewed by Cursor Bugbot for commit 7241dd8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---