fix(android): share OkHttpClient and ImageLoader across image loads (fatal TooManyRequestsException)

[tss-ashishmishra]

Summary

Fixes #440 — reloadImage() built a new OkHttpClient and a new Coil ImageLoader on every image load (the per-view ProgressInterceptor was the reason). Consequences in image-heavy apps:

• Each ImageLoader registers a ConnectivityManager network callback. Android caps an app at 100 callbacks, so rendering ~100 images crashes with a fatal android.net.ConnectivityManager$TooManyRequestsException (frequently surfacing on an unrelated thread, because the cap is app-wide).
• Each OkHttpClient owns its own dispatcher, thread, and connection pool — memory bloat and GC pressure under fast scrolling, up to OutOfMemoryError.

Approach

One shared OkHttpClient and at most two shared ImageLoaders (one per respectCacheHeaders value, driven by cachePolicy), built lazily over the Coil singleton with applicationContext.

onProgress keeps working:

• Each request is tagged with the view tag via an internal header (X-TurboImage-View-Tag) added in the Coil request builder.
• The shared ProgressInterceptor reads and strips the header before the request reaches the network, then resolves the listener from a new ProgressListeners registry (ConcurrentHashMap<Int, ProgressListener>).
• Listeners are registered per load and unregistered in onDropViewInstance, so no view leaks.

Behavior is otherwise unchanged: newBuilder() over the Coil singleton preserves the same defaults the per-load code inherited, and headers don't participate in Coil's default cache keys, so cache behavior is unaffected.

Testing

• Compiles clean against React Native 0.86 (New Architecture) with the library's Coil version.
• The shared-loader approach has been running as a production patch-package patch in a large e-commerce app (~80–90% image content): the exact browsing flow that previously crashed with TooManyRequestsException every session survived 20+ consecutive sessions crash-free, and the OOM/GC-pressure symptoms disappeared.