#2381 Image generation on Windows: sd-cli exits 0xC0000135 — lib_dirs points at <CUDA>\bin, the runtime DLLs live in bin\x64

Beschreibung

## Summary

On Windows the image build records `lib_dirs` as `<CUDA_ROOT>\bin`, but CUDA 12/13 ship the runtime libraries in `<CUDA_ROOT>\bin\x64`. `sd-cli.exe` is therefore started with a `PATH` that does not contain `cublas64_13.dll`, and every image request fails. Image generation is unusable on Windows unless the config is edited by hand.

## Environment

- Strata v0.1.44.1 — the same line is on `main`
- Windows 11, RTX 5070 Ti Laptop (12 GB), driver 617.42
- CUDA Toolkit 13.0.2, installed as the docs suggest: `winget install -e --source winget --id Nvidia.CUDA --version 13.0`
- Install itself succeeds: `.venv\Scripts\python.exe tools\image\install.py --config strata-iq3_xxs.json` builds `sd-cli` (CUDA) and downloads + SHA-256-verifies all three files (`Q6_K` 6.27 GB, text encoder 5.1 GB, VAE 0.68 GB)

## Steps to reproduce

1. On Windows, install the CUDA Toolkit 13.0 and run `tools/image/install.py` for an existing config.
2. Start the server — `GET /health` reports `"image_generation": true`, so the feature is on.
3. `POST /v1/images/generations` with `{"prompt": "a cat", "size": "512x512"}`.

## Actual result

```
HTTP 500
{"error": {"type": "server_error", "code": "image_generation_failed",
           "message": "sd-cli exited with code 3221225781; the end of its log:\n"}}
```

`3221225781` is `0xC0000135` = `STATUS_DLL_NOT_FOUND` — the loader could not resolve an import of `sd-cli.exe`. Started from a shell with `<CUDA_ROOT>\bin` on `PATH`, `sd-cli.exe` names the file it wants: `cublas64_13.dll`.

## Root cause

`setup.py:3154`, in `build_image_engine`:

```python
lib_dirs = [str(root / "bin")] if WIN else [str(d) for d in (root / "lib64", root / "lib") if d.is_dir()]
```

`tools/image/install.py` writes that list into the run config's `images.lib_dirs`, and `serve/server.py:2799` / `serve/images.py:135` prepend it to the child's `PATH`. On a CUDA 13.0.2 install:

```
<CUDA_ROOT>\bin\*.dll        0 files
<CUDA_ROOT>\bin\x64\*.dll   27 files   (cublas64_13.dll, cublasLt64_13.dll, cudart64_13.dll, ...)
```

`bin` holds the tools (`nvcc.exe`, `ptxas.exe`, `nvlink.exe`, ...) — the runtime libraries moved to `bin\x64` in CUDA 12. The Linux branch (`lib64`) is correct, so this is Windows-only.

## Suggested fix

List both, the `x64` subdirectory first, which covers every CUDA layout:

```python
lib_dirs = ([str(d) for d in (root / "bin" / "x64", root / "bin") if d.is_dir()]
            if WIN else [str(d) for d in (root / "lib64", root / "lib") if d.is_dir()])
```

## Workaround

Add `<CUDA_ROOT>\bin\x64` to `images.lib_dirs` in the run config and restart the server (the `images` section is copied into the running service at startup). After that the same GPU renders 512×512 in ~21 s and 1024×1024 in ~26 s at `Q6_K`, so nothing else is wrong here.

## Side note

The "the end of its log:" tail is empty in this case, so the user is left with a bare exit code. When a child exits with `0xC0000135`, one line saying that a library could not be found would turn this into a one-glance diagnosis.