Parallelize the split-merge orthophoto blend loop (single-threaded; complements --merge-skip-blending)

The split-merge orthophoto merge in opendm/orthophoto.py::merge() runs its block_windows() feather/cutline blending as a single-threaded numpy loop. On large-area surveys this dominates wall-clock while most cores sit idle. (Confirmed single-threaded on v3.5.6 and still on v3.6.0/master.)

Real-world evidence

A 1071-image / 18.7 GB survey at --orthophoto-resolution 1, split into 3 submodels:

• Submodel processing (matching → SfM → per-submodel ortho): ~7 h, using all 16 vCPU.
• The final merge produced a 245639 × 64592 (~15.9 gigapixel) orthophoto and then ran 10 h+ single-threaded at ~1.6 vCPU / ~10 GB RAM on a 16-vCPU / 120 GB machine — ~14 cores idle the whole time. (Matches the 80 km² Freetown observation behind #1934.)

Why it's parallelizable

block_windows() are independent output regions — each block reads its source windows, blends, and writes its own dst_window. The read+blend compute can be fanned out across a worker pool (e.g. concurrent.futures), with writes either serialized in the main thread or coordinated per-block (GDAL datasets aren't safe for concurrent writes to one handle). The block-based structure #1934 mentions is already in place.

Relation to #1934

--merge-skip-blending and the planned edge-only blending reduce how much blending happens; this issue is about parallelizing whatever blending remains. They compose. Happy to prototype a PR if there's interest in the approach.

Start in opendm/orthophoto.py at merge() and trace the block_windows() feather/cutline blending loop. Review how source windows are read and dst_window is written, then check the existing split-merge behavior before evaluating a worker-pool approach. Done means remaining blending uses available CPU cores without unsafe concurrent writes or changing merge output.