Fix Windows CUDA detection + image gen

[cryptopoly]

Summary

Two related Windows bugs surfaced during the v0.7.2 smoke test on an RTX 4090 / 24 GB box:

• Bump actions/upload-artifact from 6 to 7 #6 GPU memory misreported as 12 GB on a 24 GB card. GPUMonitor._snapshot_nvidia() shelled out to nvidia-smi, and on Windows boxes without it on PATH (driver installed but no CUDA toolkit) it fell through to _fallback_psutil(), which returns system RAM. The image / video safety estimators then read that as the GPU budget and produced spurious "Likely to crash" warnings.
• Bump tauri-apps/tauri-action from 0.6.0 to 0.6.2 #7 Image gen produces gibberish placeholder after install. DiffusersImageEngine.probe() uses importlib.util.find_spec to choose between the placeholder engine and the real diffusers pipeline. After the GPU bundle install lands new packages into the extras dir, importlib's negative-lookup cache still answers None until invalidate_caches() is called, so the probe kept reporting realGenerationAvailable=False and the SVG placeholder leaked through.

Changes

backend_service/helpers/gpu.py

• New _snapshot_torch_cuda() reads VRAM via torch.cuda.get_device_properties(0).total_memory first — works whenever the GPU bundle is installed, no PATH dependency.
• _snapshot_nvidia() now tries torch.cuda → nvidia-smi → returns vram_total_gb=None (no system-RAM lie).
• The old _fallback_psutil() is kept untouched but no longer reachable from the live path.

backend_service/image_runtime.py

• DiffusersImageEngine.probe() calls importlib.invalidate_caches() before the find_spec checks so newly-installed packages from the GPU bundle install are visible without a backend restart.

backend_service/routes/setup.py

• _gpu_bundle_job_worker invalidates the import cache and resets the VRAM total cache when transitioning to phase=done, so the immediately-following capabilities snapshot reflects freshly-importable torch.

tests/test_gpu_detection.py (new)

Nine unit tests covering:

• torch.cuda returns full 24 GB for a mocked RTX 4090.
• torch.cuda unavailable / not installed returns None.
• _snapshot_nvidia falls back to {"gpu_name": "No GPU detected", "vram_total_gb": None} when both torch.cuda and nvidia-smi fail.
• _snapshot_nvidia does NOT fall back to system RAM via psutil any more.
• torch.cuda takes precedence over nvidia-smi when both are available.
• get_device_vram_total_gb caches result for process lifetime.

Test plan

• .venv/bin/python -m pytest tests/test_gpu_detection.py -v — 9/9 pass
• .venv/bin/python -m pytest tests/test_setup_routes.py tests/test_inference.py tests/test_services.py -q — pre-existing tests still pass
• Manual verify on Windows / RTX 4090: Settings → Diagnostics reports 24 GB VRAM after restart; FLUX.1 Dev no longer triggers "Likely to crash" warning; clicking Generate after a fresh GPU bundle install produces a real image instead of the placeholder.
• Manual verify on macOS (regression): VRAM detection still reports unified memory correctly via the existing _snapshot_macos path (untouched).

Out of scope

• The diffusers/safetensors version-incompatibility warning ("safetensors 0.7.0 vs >=0.8.0-rc.0") observed in the install log is a separate issue. safetensors 0.8.0-rc.0 is a pre-release that pip won't install by default; in practice 0.7.0 works for the FLUX pipeline, so this PR leaves the pin at safetensors>=0.4.5 and treats the pip-resolver warning as benign.