libvncserver: use zlib stream for Tight level zero

[marcofortina]

Summary

Fixes Tight encoding with zlib compression level 0.

With compression level 0, Tight rectangles were sent using the rfbTightNoZlib path or by bypassing zlib in CompressData(). That means clients received raw uncompressed bytes without a zlib wrapper. Some clients, including the ones reported in #370, expect a valid zlib stream even when the selected zlib level is 0.

Changes

• Stop emitting rfbTightNoZlib for mono rectangles when the configured zlib level is 0.
• Stop emitting rfbTightNoZlib for indexed rectangles when the configured zlib level is 0.
• Stop emitting rfbTightNoZlib for full-color rectangles when the configured zlib level is 0.
• Remove the zlibLevel == 0 fast-path in CompressData() so level 0 still goes through deflateInit2() / deflate() and produces a valid zlib stream.

Validation

cmake -S . -B build-370 \
  -DWITH_EXAMPLES=OFF \
  -DWITH_TESTS=ON \
  -DWITH_OPENSSL=OFF \
  -DWITH_GNUTLS=OFF \
  -DWITH_GCRYPT=OFF \
  -DWITH_SDL=OFF \
  -DWITH_GTK=OFF \
  -DWITH_QT=OFF \
  -DWITH_FFMPEG=OFF \
  -DWITH_XCB=OFF \
  -DWITH_LIBSSHTUNNEL=OFF \
  -DWITH_SYSTEMD=OFF \
  -DCMAKE_BUILD_TYPE=Debug
cmake --build build-370 --parallel 1
ctest --test-dir build-370 --output-on-failure

Result:

100% tests passed, 0 tests failed out of 5

Notes

I did not run an interoperability smoke test with UltraVNCViewer/TightVNC. The change follows the issue report exactly and keeps level-0 zlib as uncompressed data inside a valid zlib stream.

Closes #370.