v0.1.8 — fix device-mismatch on cache-hit low_vram toggle

Fix: Input type (cuda.FloatTensor) and weight type (torch.FloatTensor) should be the same

Running the bundled demo workflow (low_vram=False) after a prior queue run
that used low_vram=True would crash with the device-mismatch error above,
at image_conditioned_proj.py:511 (DinoV3 image extractor forward).

Root cause

load_pipeline's cache-hit fast path was just setting _pipeline.low_vram = low_vram
and returning. Three submodel groups end up scattered across devices after a
low_vram=True run, and none of them get re-moved on toggle:

1. self.models (SS / shape / tex flow + decoders) — upstream Pipeline.to()
   iterates self.models.values(), but only when low_vram=False.
2. self.rembg_model — upstream pipeline.to() moves it when
   low_vram=False; in low_vram=True mode preprocess_image() does it lazily.
3. self.image_cond_model_{ss, shape_512, shape_1024, tex_1024} (4x DinoV3
   projection extractors) — these are not touched by upstream pipeline.to().
   Each get_proj_cond_* does if self.low_vram: m.to(device); …; m.cpu()
   after use, so a prior low_vram=True run parks all four on CPU. A follow-up
   low_vram=False run skips the lazy move and forward fails.

Fix

On cache hit, set self.low_vram first (so upstream's pipeline.to() picks the
correct branch), then call pipeline.to(device). When transitioning to
low_vram=False, additionally re-move the four image_cond_model_* extractors
to the device — matching what the initial-load path already does.

Verified

End-to-end with the actual toggle sequence:

• fresh load low_vram=True → 98s GLB
• cache hit, toggle to low_vram=False → 63s GLB, no device error

Full Changelog: v0.1.7...v0.1.8