Fix: Silence SOCKET_DLLLOADER log flood and tighten device-port logging

SOCKET_DLLLOADER (210) is the shellcode / memory-DLL loader asking the
server for the full DLL payload before it can load the client. The MFC
master console serves it via SendServerDll; the Go web device port has no
payload to hand out, so every memory-DLL client startup/reconnect fell
into the default dispatch branch and logged "Unhandled command 210",
flooding the log. Add a protocol constant and drop the command silently.

While auditing the device-port logging surface:

- Downgrade wrapTLS's per-connection hex-dump lines and the screen-spy
  "[timing]" cold-start line from Info to Debug (they fire once per TCP
  connection / screen view and are diagnostics, not operational events).

- Distinguish a sub-connection hijack attempt from a plain orphan: when a
  screen/terminal sub-conn claims a MasterID from a source IP other than
  the device's login conn, log a dedicated Warn instead of mislabeling it
  as "orphan ... unknown device".

Co-Authored-By: deepseek-v4-pro

server/go/protocol/commands.go

@@ -126,6 +126,7 @@ const (
 	TokenTerminalClose byte = 233 // TOKEN_TERMINAL_CLOSE - shell exited / close ack
 	TokenConnAuth      byte = 246 // TOKEN_CONN_AUTH - sub-connection identity handshake
 	CmdCursorImage     byte = 93  // CMD_CURSOR_IMAGE - custom cursor bitmap (Phase 5+ feature)
+	CmdSockDllLoader   byte = 210 // SOCKET_DLLLOADER - shellcode/memory-DLL loader requests the full DLL payload
 )
 
 // Sub-connection authentication (matches common/commands.h ConnAuth* structs).