[kean]

Four fixes in the pipeline and the task engine, one commit each.

• Creating a pipeline reset prefersIncrementalDelivery on a DataLoader shared with another pipeline, so a pipeline derived from a progressive one's configuration turned the increments off for it and it stopped producing previews. The pipeline now only ever turns the flag on for progressive decoding and never writes false, which also leaves a loader the app configured by hand alone.
• A request created after invalidate() returned could still succeed when invalidate() was called from a lower-QoS thread: both reach the pipeline actor in unstructured hops, and the task's start could overtake the invalidation. invalidate() now records the flag under the existing task-ID lock before it returns, and the task creation reads it in the same lock acquisition it already takes for the ID.
• A late progressive decode cleared AsyncTask.operation unconditionally when it finished, dropping the handle to the final decode that had replaced it, so cancelling the image task or changing its priority no longer reached the final decode. The handle is now left alone when the finishing operation was cancelled. TaskLoadImage has the same pattern for processing and decompression; it is left for the change that owns that file.
• .skipDataLoadingQueue was ignored for ImageRequest(id:image:): loadAsyncImage always went through dataLoadingQueue, unlike the URL and ImageRequest(id:data:) paths. It now runs the closure in a Task of its own, cancelled through onCancelled like the data-closure path.

The imageTaskCreated wiring fix moved to #1086.