Document and package the new libjpeg-turbo dependency

Tight's JPEG sub-mode (previous commit) links libjpeg-turbo directly.
Adds it to docs/BUILDING.md for all three platforms (apt
libjpeg-turbo8-dev, brew jpeg-turbo, vcpkg libjpeg-turbo:x64-windows)
and to the .deb package's Depends: line (libjpeg-turbo8). No changes
needed for Windows (the Inno Setup script already wildcards *.dll) or
macOS (macdeployqt bundles non-system dylibs automatically). Left the
Flatpak manifests unchanged on the assumption that the KDE runtime
already bundles libjpeg-turbo as a standard Qt JPEG-plugin dependency
-- flagged in PROGRESS.md as worth confirming next time a Flatpak
build actually runs, since that wasn't independently verified here.

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

docs/PROGRESS.md

@@ -199,6 +199,16 @@ follow-up tracking):
   is the least exercised/confirmed of the three filters against a real
   server in this pass (most real-world Tight traffic uses Copy or
   Palette)
+- Packaging for the new `libjpeg-turbo` dependency: added to
+  `docs/BUILDING.md` (apt/brew/vcpkg) and the `.deb` control file's
+  `Depends:` (`libjpeg-turbo8`). The Windows Inno Setup script already
+  wildcards `*.dll` so no change was needed there, and macOS's
+  `macdeployqt`-based bundling picks up non-system dylibs automatically.
+  The Flatpak manifests (`packaging/flatpak/*.yml`) were left unchanged on
+  the assumption that `org.kde.Platform`/`Sdk` 6.11 already bundles
+  libjpeg-turbo (a standard Qt JPEG-plugin dependency) -- worth confirming
+  the next time a Flatpak build is actually run, since it wasn't
+  independently verified here
 - No dynamic resize (connects at the server's native resolution; the
   `Scale to Fit`/`Actual Size` toggle changes how that fixed resolution is
   displayed locally, not what resolution is requested from the guest --