[Feature request]: Resolve GoogleNavigation via Swift Package Manager — the CocoaPods pod stops at 10.15.0 and conflicts with SPM-based libraries

### Summary

`@googlemaps/react-native-navigation-sdk` resolves its native dependency through CocoaPods
(`s.dependency "GoogleNavigation", "10.13.0"` in 0.16.3). Two problems follow from that:

1. **The pod is behind and appears to be end-of-line.** CocoaPods trunk carries
`GoogleNavigation` up to **10.15.0**, while **11.0.0** is the current release in
[googlemaps/ios-navigation-sdk](https://github.com/googlemaps/ios-navigation-sdk/releases)
and is not published to CocoaPods. So the wrapper currently has no route to 11.x.
2. **The pod's static linkage conflicts with libraries that resolve their native dependencies
via SPM.** Concretely, any app that combines this library with `react-native-firebase`
**>= 26.1.0** cannot complete `pod install` (details and both error messages below).

Is SPM resolution planned for this wrapper, and is there a rough timeline we could plan against?

### Why this is time-sensitive

From the [Navigation SDK for iOS release notes](https://developers.google.com/maps/documentation/navigation/ios-sdk/release-notes),
under the August 18, 2025 entry:

> CocoaPods is in maintenance mode as of 8/18/2025 and we won't release more versions of CocoaPods after Q2 2026.

Swift Package Manager has been available for a while — from the
[Google Maps Platform announcement](https://mapsplatform.google.com/resources/blog/google-maps-platform-sdks-for-ios-now-available-through-swift-package-manager/):

> Swift Package Manager support is available for Google Maps Platform SDKs beginning with version 8.3.1 of the Maps SDK for iOS, version 8.3.0 of Places SDK for iOS, and version 5.3.1 of the Navigation SDK for iOS.

Current pod versions can be checked with:

```
curl -s https://trunk.cocoapods.org/api/v1/pods/GoogleNavigation | jq '.versions[].name'
```

At the time of writing this returns 10.15.0 as the highest version, with no 11.x.

### The concrete conflict with react-native-firebase

`react-native-firebase` 26.1.0 resolves the Firebase Apple SDK via SPM by default and requires
dynamic linkage. `GoogleNavigation.xcframework` as distributed through CocoaPods is a **static**
archive:

```
$ file Pods/GoogleNavigation/Frameworks/GoogleNavigation.xcframework/ios-arm64_x86_64-simulator/GoogleNavigation.framework/GoogleNavigation
Mach-O universal binary with 2 architectures:
[x86_64:current ar archive random library] [arm64]
```

Because CocoaPods' `use_frameworks!` is an all-or-nothing decision per target, the two cannot
coexist. Both directions fail at `pod install`:

**With static linkage** (`use_frameworks! :linkage => :static`):

```
[react-native-firebase] SPM + static linkage is not supported (target(s): Pods-).

firebase-ios-sdk's Swift Package only ships dynamic library products, so
`use_frameworks! :linkage => :static` causes every react-native-firebase pod that resolves
Firebase via SPM to embed its own copy of the same Firebase frameworks -- this produces
duplicate-symbol linker errors at build time instead of a clear error here.
```

**With dynamic linkage** (`use_frameworks! :linkage => :dynamic`):

```
The 'Pods-' target has transitive dependencies that include statically linked binaries:
(.../Pods/GoogleNavigation/Frameworks/GoogleNavigation.xcframework)
```

The only workaround today is `$RNFirebaseDisableSPM = true`, which keeps Firebase on CocoaPods —
i.e. it opts out of the migration Firebase is asking everyone to make before their own CocoaPods
cutoff. That is a stopgap, not a solution.

### Environment

| | |
|---|---|
| `@googlemaps/react-native-navigation-sdk` | 0.16.3 |
| `GoogleNavigation` pod (pinned by podspec) | 10.13.0 |
| `@react-native-firebase/*` | 26.1.0 |
| react-native | 0.86.2 |
| expo | 57.0.11 (prebuild / dev client) |
| CocoaPods | 1.16.2 |
| Xcode | 26.6 |
| iOS deployment target | 16.4 |

Reproduces on a clean `expo prebuild --clean --platform ios`.

### Suggested approach

React Native provides an `spm_dependency` podspec helper that lets a podspec declare an SPM
dependency while still being consumed through CocoaPods autolinking.

`react-native-firebase` uses exactly this, with a CocoaPods fallback when the helper is unavailable
(its fallback message states "SPM not available (React Native < 0.75)"). The pattern, from
`firebase_spm.rb` in that project:

```ruby
if defined?(spm_dependency) && !rnfirebase_spm_disabled?
spm_dependency(spec,
url: 'https://github.com/firebase/firebase-ios-sdk.git',
requirement: { kind: 'upToNextMajorVersion', minimumVersion: version },
products: spm_products
)
else
spec.dependency pod, version # CocoaPods fallback
end
```

Applying the same pattern here, pointing at `https://github.com/googlemaps/ios-navigation-sdk`,
would keep older React Native versions working via the fallback while unblocking 11.x and
coexistence with SPM-based libraries.

An opt-out global (as `$RNFirebaseDisableSPM` does) would be a useful escape hatch during the
transition.