Always queue image delivery services

[LordMike]

Why

I tested the clean-port branch on a Home Assistant instance using bleproxy to reach a display over a weak, long-range BLE connection. The display does eventually receive images, but a tiny drawcustom "Hello World" payload took 25 seconds before the service call returned; another run took 36 seconds.

That delay comes from the current opportunistic behavior: if the device was seen recently, the service tries live delivery first and only queues if that path does not complete. The problem is that the service call is now indeterministic and cannot be relied on. As a script or automation author, I cannot assume that the service will complete quickly or slowly, and I cannot assume that the image has rendered or not. I must instead inspect the response to see whether it was queued.

This PR makes image services use one deterministic contract: render/prepare the image, submit it to delivery, and return once the queue accepts it. The delivery queue can still immediately try to drain in the background when the device appears reachable, but physical delivery is represented by queue state/events rather than inferred from service-call duration.

That avoids a misleading automation contract. A user should not see one drawcustom call block until the panel updates and then reasonably assume "when this service returns, the image has rendered", only for a later call to return after queueing because the BLE timing was different.

What Changed

• Image services now always submit prepared images to DeliveryManager.
• The service path no longer performs BLE reachability probing before queueing.
• New queue submissions always request a background drain; the drain path owns reachability checks and retries.
• If a newer image is queued while an older image is already sending, the newer image stays queued and is drained next instead of being cleared by the older send completing.
• If an older in-flight send fails after being superseded, that failure no longer increments attempts or sets errors on the newer queued image.
• Tests cover deterministic queueing, no service-level BLE lookup, immediate drain requests, and mid-delivery replacement behavior.

Validation

• PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=/mnt/n/Personal/opendisplay-work/Home_Assistant_Integration /home/mike/.venvs/hass-dev/bin/python -m pytest -q tests -p no:cacheprovider
• Result: 44 passed

This PR was sparked by my comment here: #31 (comment), and developed by codex and tested against a reTerminal E1002.

[g4bri3lDev]

@davelee98