fix(ios): apply the travel mode to the navigation session

[christian-apollo]

On iOS the travel mode passed to setDestinations was only applied to the GMSMapView of each registered NavigationView, never to the GMSNavigationSession whose navigator computes the route. When setDestinations runs before the view has attached to the session (the first request after a launch, when the view mounts in the same React commit that starts guidance), the session keeps its default of driving and a cycling or walking request comes back as a driving route. Re-issuing the request once the view is attached works, which is the workaround users find.

This sets the mode on the session in configureNavigatorWithTravelMode: before the views are updated, so the request itself carries it, and makes a view that attaches later take the session's mode in attachToNavigationSessionIfNeeded instead of keeping a fresh map view's default.

Verified on an iPhone 17 Pro simulator (iOS 26.4, RN 0.86.3) with a cold launch and a destination chosen from a plain MapView: before, the first route was 18.2 km in 46 min with delaySeverity: 2 (a driving route); after, 29.6 km in 96 min with delaySeverity: 0, identical to an explicit cycling request on an attached view. Walking and driving requests still return their own routes. Android is untouched: its RoutingOptions carry the mode per request.

Fixes #655

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (no documented behaviour changes)
• I added new tests to check the change I am making (no test harness covers the native iOS session; verified manually as described above)
• All existing and new tests are passing.