Prevent image-transform worker deadlocks

[clemsgrs]

Summary

• resolve automatically selected dense- and pooled-image transform workers to zero after the model runtime is initialized
• preserve explicit positive worker counts with a safe spawn DataLoader context
• retain distributed sharding/output semantics and add bounded public-API subprocess regressions

Root cause

The image embedding paths loaded the encoder/runtime before constructing a DataLoader. Default worker selection then forked transform workers from a parent with initialized native threads, which could leave sleeping workers and deadlock the run.

User impact

Default dense-image and pooled-image embedding now complete without post-runtime worker forks. Explicit zero remains supported, while callers that explicitly request worker parallelism keep it through spawned workers.

Validation

• 140 relevant tests passed across dense/pooled image stages, shards, batching, and core execution options
• bounded public Model.embed_images_dense(...) and Model.embed_images(...) subprocess regressions passed and reported no active child workers
• explicit spawned distributed dense and pooled worker tests passed with preserved shard outputs
• git diff --check passed
• two-axis main...HEAD review passed after both Standards judgement calls were resolved; Spec reported no findings

Closes #245