MAINT Consolidate duplicate image URL download handling

@nightcityblade is already working on this.

Since Aug 19, 2026.

#### 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.