fix(ios): break strong retain cycles in method-channel and custom-style callbacks

[hebaek76916]

Summary

Fixes a critical iOS memory leak where NaverMapView, NaverMapController, OverlayController, and the underlying NMFNaverMapView are never deallocated after a map screen is disposed. Apps that open/close the map repeatedly eventually hit the iOS memory high-watermark (~2 GB) and are killed by the OS.

Crash signature:

Root Cause

Four separate strong retain cycles caused by passing instance methods as closure arguments. In Swift, channel.setMethodCallHandler(handle) implicitly captures self strongly, creating cycles that ARC cannot break.

Cycle 1 — NaverMapController.init

channel.setMethodCallHandler(handle) → FlutterMethodChannel → closure → self

Cycle 2 — OverlayController.init

channel.setMethodCallHandler(handler) → same pattern

Cycle 3 — NaverMapControlSenderExtensions (the real killer)

loadHandler: onCustomStyleLoaded → stored inside NMFMapView → creates NMFNaverMapView ↔ NaverMapController cycle

Cycle 4 — NaverMapViewEventDelegate.registerDelegates

loadHandler: sender?.onCustomStyleLoaded → promotes optional, captures sender strongly

Fix

All four wrap callbacks in explicit { [weak self] in self?.method() } closures. Added deinit to NaverMapController and OverlayController to clear method-channel handlers. Added delegate-unregister + removeFromSuperview() in NaverMapView.deinit as safety net.

Verification

Tested with Xcode Memory Graph after 4+ map-screen push/pop cycles:

Before (3 visits):

• NaverMapController (3), OverlayController (3), NMFNaverMapView (3), NOverlayInfo (2039)
• Memory climbs to ~1.37 GB and never recovers

After (4 visits):

• All counts stay at (1) — only singletons remain
• Memory returns to baseline after each pop
• All deinit methods fire on every pop

Checklist

• Tested on iOS 17
• Verified no regression in existing map/overlay functionality
• Android behavior unchanged (no Android code modified)

cf)

After Fix