MAINT Consolidate duplicate image URL download handling

Is your feature request related to a problem? Please describe.

BaseImageToImageConverter._read_image_from_url_async and ImageCompressionConverter._read_image_from_url_async contain an exact duplicate asynchronous image URL downloader and error wrapper (approximately 19 lines each).

The duplication creates two places to maintain HTTP behavior, response handling, and user-facing RuntimeError semantics. The current implementations are small, but divergence could cause transform converters and image compression to treat the same URL failure differently.

Describe the solution you'd like

Consolidate the shared behavior into one converter-internal asynchronous helper that preserves:

• the existing aiohttp request and response semantics;
• exact error wrapping and message behavior;
• byte-return behavior;
• cancellation and exception propagation;
• compatibility for subclasses of BaseImageToImageConverter.

Delete the duplicate implementation and have both converter paths use the shared helper. Keep the helper internal unless there is concrete evidence that it should become a supported extension point.

Describe alternatives you've considered, if relevant

Making ImageCompressionConverter inherit from BaseImageToImageConverter would create an artificial type relationship and pull in unrelated behavior. A standalone internal helper is simpler. Keeping both methods is viable but leaves a confirmed duplicate network/error contract.

Additional context

Before changing the method surface, inspect whether external or in-repository subclasses override _read_image_from_url_async. If override compatibility matters, retain a delegating method on the base class rather than removing the hook.

Validation should cover:

• all base image-to-image transform converter tests;
• image compression tests;
• successful URL reads;
• non-success HTTP responses;
• connection and body-read errors;
• exact exception text/type;
• cancellation propagation;
• subclass override compatibility.

This is the lowest-risk candidate of the five, with moderate extension-point risk and a clear deletion/consolidation benefit.