fix: serialize torch module construction to prevent cross-thread meta-tensor leak

[lstein]

Summary

Serializes the three remaining direct torch model constructions under MODEL_LOAD_LOCK, closing the cross-thread meta-tensor leak for code paths outside the model-load machinery.

Background. transformers' from_pretrained constructs models under accelerate's init_empty_weights, which monkeypatches nn.Module.register_parameter as a class attribute and restores the saved original on exit. Two overlapping constructions on different threads each save the other's patched attribute as "the original", and one patch leaks permanently — after which every module constructed in the process gets meta-device parameters (NotImplementedError: Cannot copy out of meta tensor; no data!) until restart. Reproduced empirically; hit in the field when image-index worker/request threads began loading models concurrently with generation.

main already serializes the loader paths under MODEL_LOAD_LOCK (an earlier revision of this PR added equivalent locking for the v7 branch — superseded). Three sites still construct torch modules outside it:

• SafetyChecker (session thread, after every generation when the NSFW checker is on). Its first-run download now happens via snapshot_download before taking the lock, so a multi-GB transfer can't stall every other model load.
• Quantized Qwen2.5-VL encoder load.
• ESRGAN RRDBNet constructions.

All three take MODEL_LOAD_LOCK.write_lock() around construction only, per the lock-ordering contract documented on _ModelLoadReadWriteLock (this lock before any ModelCache lock; none of these sites touch the cache).

Testing

• ruff + format clean; modules import cleanly under main's locked dependency set.
• The leak mechanism and fix shape were validated empirically on the v7 revision of this PR (isolated two-thread repro of the accelerate patch leak, plus a threading regression test of the equivalent lock).

🤖 Generated with Claude Code

[joshistoast]

change merge destination to main