perf(service): parallelize intra-task tile merge (MAPCO-11325)

[shimoncohen]

SVC-1 of MAPCO-11318. Stacked on #255 (MAPCO-11320) — base branch is logic-1-gpkgclient-perf, not master, so this diff shows only the SVC-1 change. Retarget to master after #255 merges.

Change

The service merged tiles sequentially in a nested x/y loop. Merge is the hot path and each coord is independent, so:

• Enumerate each batch's coords and process them in chunks of batchMaxSize, merging each chunk's coords with Parallel.ForEach into a ConcurrentBag, then flushing the chunk to the target before starting the next.
• Memory stays bounded to ~one chunk (count-based). With the default batchMaxSize=1000, that's ≈ the previous 20 MB byte cap for jpeg tiles. Per the design decision, the precise byte cap is approximated by the count cap.
• Concurrency safety: within a chunk the target is only read (the single write happens after the parallel phase), and GetCorrespondingTile is thread-safe per data source — so this relies on the thread-safe GpkgClient connection from perf(gpkg): connection reuse + prepared bulk-insert + keyset paging (MAPCO-11320) #255.
• DOP is configurable via GENERAL:parallel:numOfThreads (0/unset → Environment.ProcessorCount).

Scope — delivers P9 of MAPCO-11325 only

MAPCO-11325 scopes four points; this PR implements P9 (parallelize the intra-task merge). The rest remain open in that ticket and are intentionally out of scope here:

• P17 — whole-task dispatch concurrency (MainRunner: one task at a time process-wide → per-type bounded workers). Job-state/heartbeat complexity; separate change.
• P18 — progress HTTP PUT throttling (blocking PUT every batch and every flush).
• P15 — job-callback caching (HTTP GET per task for the callback URL).

Separately, the count-based memory cap here is an approximation of the old byte-accurate 20 MB bound; tracked as its own follow-up in MAPCO-11367.

Testing

Full suite: 1142 passed, 0 failed. The batch-flush test now uses dense bounds and asserts count-based (chunked) flushing.

Depends on

• perf(gpkg): connection reuse + prepared bulk-insert + keyset paging (MAPCO-11320) #255 (MAPCO-11320) — required for the thread-safe connection.

🤖 Generated with Claude Code

[asafmas-rnd]

Check that Parallel doesn't call other parallel's

[shimoncohen]

Check that Parallel doesn't call other parallel's

Checked. There is one real nest: this PR's outer Parallel.ForEach (TaskExecutor) → GetCorrespondingTile → InternalGetLastExistingTile, which has had an unbounded Parallel.ForEachAsync + sync-over-async .Result since #119. Under the outer loop that blocks a worker thread while inner items compete for the same pool → thread-pool starvation. Correctness is fine (independent loops, connection-guarded), the hazard is perf-only and gated to the upscale-fallback path.

The pre-existing S3 InternalUpdateTiles parallel runs sequentially per chunk, outside the merge phase — not nested, no compounding.

Fixed the inner parallel in #264 (sequential highest-zoom-first, short-circuits): #264