Fix: keep m_bShouldUnmask latched TRUE once a connection is HTTP

HeaderParser::Parse reset m_bShouldUnmask to FALSE on any non-HTTP
maskType, including the continuation chunk of an HTTP connection whose
read offset is already past the "POST " header. When a large packet
(e.g. a >1460-byte process list) was split by MSS, the second chunk
latched the flag to FALSE, so the next new HTTP-masked packet was no
longer unmasked: CheckHead then read the HTTP header as the flag,
returned FLAG_UNKNOWN/PARSER_FAILED, and the packet was dropped. This
explains "first packet succeeds, subsequent packets vanish", and why
the MFC process dialog went blank after killing a process (the confirm
packet never reached NotifyProc).

Only clear the flag when the connection was not already determined to
be HTTP (initial -1, or already confirmed non-HTTP).

Co-Authored-By: deepseek-v4-pro

server/2015Remote/Server.h

@@ -112,7 +112,12 @@ protected:
             m_bShouldUnmask = TRUE;
             std::string clientIP = getXForwardedFor(str);
             if (!clientIP.empty()) peer = clientIP;
-        } else {
+        } else if (m_bShouldUnmask != TRUE) {
+            // 仅当连接尚未被判定为 HTTP（初始 -1，或已确认非 HTTP）时才置为 FALSE。
+            // 否则会误伤 HTTP 连接的分片续包：续包到达时读位置已越过掩码头，
+            // TryUnMask 找不到 "POST "（maskType==None），若在这里把 m_bShouldUnmask
+            // 从 TRUE 改回 FALSE，下一个新包（仍是 HTTP 掩码）就不再解掩码，从而被 Parse
+            // 判为 PARSER_FAILED。这正是「kill 后进程列表确认包到不了 NotifyProc」的根因。
             m_bShouldUnmask = FALSE;
         }
         if (nullptr == m_Masker) {