chore: dedupe pipeline call-state httpClient and reload/toBlocking

[OmarAlJarrah]

Behavior-preserving cleanups in the sdk-core HTTP pipeline runtime (org.dexpace.sdk.core.http.pipeline). No public-API or observable-behavior change; each item removes code that duplicates logic already living one call away.

Closes #171.

Changes

• Drop the stored httpClient from PipelineCallState / AsyncPipelineCallState. The field was always the same instance as pipeline.httpClient — the cursor is only ever built from send/sendAsync (which pass their own client) and from copy (which forwards it). The sole readers, PipelineNext.process and AsyncPipelineNext.processAsync, now reach the client through pipeline, which removes the field, the constructor parameter, and one argument from every construction site. The async file also drops its now-unused AsyncHttpClient import.

• reload() replays through append(). It previously re-implemented append()'s stage-dispatch loop verbatim. Since reload clears the pillar map first and a flattened list holds at most one pillar per stage, the pillar-replacement callback never fires during replay — bucketing policy now lives in one place.

• build() uses List.toTypedArray() instead of the manual Array(size) { ordered[it] }, in both the sync and async builders. flatten() returns a non-null element list, so this yields the exact array type the constructors expect, empty case included.

• toBlocking() delegates to AsyncHttpClient.asBlocking() rather than hand-rolling the identical blocking future.get() with interrupt handling (restore-flag → cancel(true) → InterruptedIOException) and ExecutionException unwrapping. The cancellation contract now has a single definition.

• Doc fix for Stage.order. The KDoc claimed the builder emits steps by reading the numeric order; it doesn't — flatten() walks Stage.entries (declaration order) and never consults order. The values happen to ascend with declaration order, which is why output stays sorted. Corrected the KDoc and the matching test comment so nobody tries to reorder steps by renumbering order. The order property is retained as a stable inspection key.

Verification

./gradlew :sdk-core:build passes — ktlint, detekt, allWarningsAsErrors, binary-compatibility check, tests, and the coverage gate. All changed declarations are internal or signature-unchanged, so there is no apiCheck impact.