chore(spawn-docker-jdk): drive PullImage off the /images/create progress stream

[deer]

PullImage previously extended AbstractEventBasedBlockingCommand and blocked by subscribing to the session-wide Publisher<Event>, waiting for an ActionEvent whose action was pull and whose id matched the requested image. This coupled a single image pull to the shared system-event stream, and if that event never arrived the command would either block indefinitely in processing.join() or report success regardless of what actually happened.

PullImage now extends AbstractBlockingCommand and consumes the /images/create response body directly. The response is a stream of newline-delimited JSON progress objects that the Docker Engine holds open until the pull completes or fails; createResult reads that stream to exhaustion via JsonNodeInputStreamProcessor and inspects each object. A terminal status value beginning with Status: (covering both Status: Downloaded newer image for ... and Status: Image is up to date for ...) marks success. An in-band error field, which the Docker Engine reports while the HTTP status stays 200, is captured and rethrown as an IOException. A stream that ends without either a terminal status or an error, such as a connection dropped mid-pull, is also treated as a failure. Observations are collected on a small single-threaded PullOutcome holder since JsonNodeInputStreamProcessor delivers every object synchronously on the calling thread.

AbstractEventBasedBlockingCommand had no other subclasses and is deleted. One caller-visible consequence: Session.pull(...) now throws (a RuntimeException wrapping the IOException, via AbstractCommand.onRequestFailed) when a pull fails or its progress stream is truncated, instead of blocking or returning a value.