#3372 [Engine] serve: recreate the vision encoder's work dir when a temp cleaner removed it

本文

**[Engine] — the title above starts with the area.**

## Problem and result

An idle encoder's work dir (`%TEMP%\strata-vision-*`) sits empty and unheld in the temp directory for as long as the model stays unloaded, and Windows' Storage Sense (or any temp cleaner) removes it there. Every later start then failed on the encoder's cwd with `[WinError 267] The directory name is invalid`, on every client retry, until the whole server was restarted: `work_dir()` runs once at the server's start and `restart()` reuses the stale path.

After the fix, `Vision._start()` recreates the dir (and drops the encoded-image cache, whose files lived in it) before either the GPU or the CPU-fallback reader is spawned, so an unload/load cycle survives an external removal of the directory.

## Related discussion

#3370 (the full evidence chain: production timeline, ruled-out causes, minimal reproduction).

## Approach

The check lives in `_start`, the wrapper, so both the GPU reader and the CPU fallback start against an existing dir. The cache is dropped along with the dir because the cache-hit branch of `encode()` returns paths without checking they exist — stale entries would hand the engine paths into a directory that no longer exists. No compatibility effects outside the broken case: a dir that exists is left untouched, and `work_dir()` is the same #480-selected space-free path as before.

## Validation

**Passed:**

- `python3 -m serve.test_vision_dir` — both cases (removed dir recreated + cache dropped; intact dir kept with its cache), at e88ee39d + this patch, Ubuntu, CPython 3.12
- `python3 -m serve.test_vision_busy` — the existing vision-start tests, no regression (4/4)
- the equivalent one-line fix has run on the affected production machine (Windows 11, RTX 3090, engine 0.1.45) since 2026-10-20: `py_compile` clean; the load-after-idle path had been failing daily before the fix

**Failed:**

- none observed

**Not run:**

- a real GPU encoder start against a removed dir on Windows (the production machine has the fix and has not hit the condition since; the unit test covers the logic with the spawn mocked)
- CUDA / HIP / SYCL / Metal builds of the engine — the change is serve-side Python only

## Limits

The recreated dir is a new directory: anything holding a path into the old one goes stale. The server itself holds no such paths (the cache is dropped with the recreation), and the encoder is spawned fresh in the new dir — so nothing inside the server can observe the switch.