Fix: Decode process list names/paths as GBK on Windows

Process management decoded the client's process name/path bytes with
GetClientEncoding, which returns UTF-8 for CLIENT_CAP_UTF8 clients. But
the Windows client builds the process list with the ANSI A-interface
(Process32FirstA / QueryFullProcessImageNameA), which emits the client's
system code page (GBK on Chinese Windows) regardless of the UTF-8
capability -- unlike window titles, which were migrated to the
W-interface plus UTF-8. Decoding GBK as UTF-8 garbled Chinese process
names and paths.

Add GetProcessListEncoding(): 936 for Windows clients, UTF-8 for
LNX/MAC, matching McpServer::BuildListProcesses, and use it in
ShowProcessList (which still writes via LVM_SETITEMTEXTW).

Also raise the IP history cap to 1000 and rename the experimental
"隐私屏幕" menu item to "虚拟屏幕".

Co-Authored-By: deepseek-v4-pro

server/2015Remote/2015RemoteDlg.h

@@ -109,6 +109,13 @@ bool SupportsFileTransferV2(context* ctx);
 // 找不到主连接或老客户端：默认 CP936（覆盖 95% 简中/英语 ASCII 老客户端）。
 UINT GetClientEncoding(context* ctx);
 
+// 获取客户端「进程名/路径」编码 (CP_UTF8 或 936)。
+// 与 GetClientEncoding 不同：Windows 客户端的进程名/路径由 A 接口
+// （Process32FirstA / QueryFullProcessImageNameA 等）生成，恒为客户端系统
+// ANSI（简中=GBK/936），不随 CLIENT_CAP_UTF8 转 UTF-8；仅 LNX/MAC 走 UTF-8。
+// 与 McpServer::BuildListProcesses 的判定保持一致。
+UINT GetProcessListEncoding(context* ctx);
+
 // 服务端待续传的传输信息
 struct PendingTransferV2 {
     uint64_t clientID;