fix(ios): hold navigation views weakly in the view registry so they deallocate on teardown

[rafmsou]

Summary

On iOS, every GoogleMapsMapView / GoogleMapsNavigationView is retained for the lifetime of the process, so repeatedly creating and disposing map/nav views grows memory without bound and eventually leads to jetsam/WatchdogTermination on memory-constrained devices.

GoogleMapsNavigationViewRegistry stored views in a strong dictionary:

private var views: [Int64: GoogleMapsNavigationView] = [:]

but a view removes itself from the registry only in its deinit (unregisterView()). The strong entry keeps the view's reference count above zero after Flutter tears down the platform view, so deinit never runs, unregisterView() is never called, and the view (and its underlying GMSMapView) leaks forever. Flutter assigns a new viewId per platform-view creation, so nothing overwrites the stale entry either — one view leaks per view creation.

This is a self-referential retain: the only code that removes a view from the registry runs in deinit, which the registry's own strong reference prevents from ever running.

Fix

Hold views through a small WeakViewRef wrapper instead of strongly. A released view then deallocates, deinit runs, and the entry is pruned. unregisterView also removes entries whose weak reference has already been reclaimed, so stale keys can't accumulate. All read accessors compactMap over live views.

CarPlay handling is unchanged: carPlayView has an explicit unregisterCarPlayView() call path (from BaseCarSceneDelegate) and never depended on deinit, so it was not affected by this leak.

Reproduction / verification

1. Show a screen containing a GoogleMapsMapView, dismiss it, repeat.
2. Profile in Instruments (Activity Monitor) on a physical device.

Measured on an iPhone 11 / iOS 26.5: physical footprint climbed ~85 MB → ~595 MB over ~4.5 min of open/close cycles with no reclamation (~88 MB/min) before the change; after the change it reclaims between cycles.

Present at least through 0.9.4 and 0.10.0 (identical registry code).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[illuminati1911]

Thanks a lot for the contribution. Few changes and I think should be good to go.