fix: resolve open issue batch — #1172 #1173 #1174 #1185 #1186 #1188

- validate managed binaries before exec; 0-byte GGUF placeholders fail
  actionably instead of "Exec format error" (#1172)
- KittenTTS: tokenizer-measured chunking to the ONNX 512-token cap;
  clear 400 for unspeakable input (#1173)
- clean SIGTERM during weight load: shutdown-aware loader, benign
  cancelled-load classification, lifespan hardening, scoped log
  silencers (transformers load + alembic fileConfig) (#1174)
- broken ASR deep-imports (lightning_fabric) mark the engine
  unavailable with a repair hint and fall through (#1185)
- uv cache + managed Python follow the chosen install drive on
  Windows (cherry-picked cross-drive class fix + spaces/D: tests) (#1186)
- adaptive silence-removal ladder for quiet clone references; localized
  actionable error for truly silent clips, all 21 locales (#1188)
- CHANGELOG: consolidated Unreleased into the quiet one-liner style

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/install/windows.md

@@ -94,6 +94,16 @@ drive (D:, E:, …). Two caveats:
   in-app, or `OMNIVOICE_DATA_DIR` / [Portable mode](#portable-install) for
   the whole data tree.
 
+When the Python **environment folder** (first-run setup → Advanced, or
+portable mode) is on a different drive than Windows, the installer keeps
+uv's package cache and managed Python **inside the environment folder**
+(`uv-cache/`, `uv-python/`) instead of `%LOCALAPPDATA%\uv`. Without that,
+every wheel (PyTorch alone is several GB) would be staged on `C:` and then
+copied across drives — filling the system drive you were trying to spare.
+The same applies to engine sidecar installs when the data directory is on
+another drive (`engines\.uv-cache`). An explicit `UV_CACHE_DIR` /
+`UV_PYTHON_INSTALL_DIR` you set yourself always wins.
+
 If an install to a local non-C: drive fails anyway, capture a log with
 `msiexec /i OmniVoice*.msi /L*V install.log` and
 [open an issue](https://github.com/debpalash/OmniVoice-Studio/issues) with it