Feat: One-way TLS transport for the device port

Add optional one-way TLS on the device port (6543), enabled per client via a
pinned trust anchor, so new clients encrypt their transport while legacy
plaintext clients keep working unchanged.

Server (server/go): sniff each accepted connection and wrap TLS peers
(ClientHello 0x16 0x03 + handshake type 0x01) in crypto/tls with MinVersion
TLS 1.2; everything else stays on the plaintext path. TLS is enabled only when
both YAMA_TLS_CERT and YAMA_TLS_KEY are set, and a cert/key load failure fails
startup loudly rather than silently serving plaintext.

Client (client/, Windows): Schannel one-way TLS. When the trust anchor is
present — registry value Software\<exehash>\settings\tls_cert (REG_SZ holding
the PEM), with fallback to settings.ini [settings] tls_cert or yama-ca.pem
beside the exe — every outbound connection (main + sub-connections) completes
a TLS 1.2 handshake before the app protocol and is strictly pinned to that
anchor via a chain engine with hExclusiveRoot; any handshake/cert failure is
fail-closed (no plaintext downgrade). Send uses EncryptMessage; Recv uses
DecryptMessage and reads plaintext from the stream-mode DATA segment (bufs[1])
rather than the record header.

Co-Authored-By: deepseek-v4-pro

client/ghost_vs2015.vcxproj

@@ -233,6 +233,7 @@
     <ClCompile Include="CFFmpegH264Encoder.cpp" />
     <ClCompile Include="EncoderFactory.cpp" />
     <ClCompile Include="TalkManager.cpp" />
+    <ClCompile Include="TlsChannel.cpp" />
     <ClCompile Include="ChatManager.cpp" />
     <ClCompile Include="MachineManager.cpp" />
     <ClCompile Include="VideoManager.cpp" />
@@ -299,6 +300,7 @@
     <ClInclude Include="SystemManager.h" />
     <ClInclude Include="VideoEncoderBase.h" />
     <ClInclude Include="TalkManager.h" />
+    <ClInclude Include="TlsChannel.h" />
     <ClInclude Include="ChatManager.h" />
     <ClInclude Include="MachineManager.h" />
     <ClInclude Include="yapi.hpp" />