PR #541 committed a large amount of Windows binary dependencies directly into the source tree, rather than pulling them via vcpkg as the rest of the project already does.

Sizes (as checked in)

These are referenced from client_generic/MSVC/electricsheep.vcxproj as include/lib search paths.

Why this is bad

1. vcpkg is already the project's declared dependency manager. vcpkg.json and vcpkg/ are used by the macOS build. There's no reason Windows can't use the same mechanism — vcpkg supports MSVC + clang-cl natively, and all five of these libraries are already in the vcpkg registry (boost-*, ffmpeg, openssl, curl, socket.io-client-cpp).
2. Repo bloat. ~440 MB of binary blobs in git history is expensive to clone, slow for CI, and impossible to garbage-collect once committed without history rewrites.
3. Ancient versions. openssl-1.0.2k (2017, EOL'd in 2019) and a pinned ffmpeg-6.1.1-93 are stuck at whatever snapshot was vendored, with no upgrade path. openssl 1.0.2 in particular has known unpatched CVEs.
4. Unreproducible. There's no way to regenerate these .lib files from source — we'd have to trust whatever machine built them originally.
5. Mixed with project sources. boost/win32/, ffmpeg/win32/, curl/lib/, openssl-1.0.2k/ and socket.io-client-cpp/lib/ sit alongside first-party source directories, making it harder to see where the project's own code ends.

Proposed fix

• Add the missing ports to vcpkg.json (boost-* subset, ffmpeg[core features], openssl, curl, socket.io-client-cpp).
• Update electricsheep.vcxproj to consume vcpkg include/lib paths instead of the hardcoded client_generic\*\win32\* paths.
• git rm -r the five vendored directories.
• Verify the Windows build still works end-to-end.

This is a larger change — splitting into one issue so it can be scoped/owned separately from the smaller cleanup items (lua5.1-old, RuntimeMSVC).