LuaMenu: load LuaSocket socket.lua from the base VFS

[tomjn]

What

CLuaMenu::InitLuaSocket loaded a bare "socket.lua" from the default VFS
(SPRING_VFS_RAW_FIRST). That path never resolves: the file actually ships in
springcontent.sdz at LuaSocket/socket.lua. So the menu/lobby's LuaSocket
layer never initialised, logged Error loading socket.lua, and Chobby could
not connect to multiplayer servers.

It now loads LuaSocket/socket.lua from SPRING_VFS_BASE with a FileExists
guard, exactly matching the already-correct CLuaUI::InitLuaSocket.

Why this is cross-platform

This is a general VFS-path bug, not platform-specific. The lookup fails on every
platform because the requested path/mode never matched the file's actual
location in the base content; it merely surfaced first during macOS lobby
testing. The fix brings the menu's socket init in line with the in-game UI's,
which has always used the correct path and mode.

Verification

engine-headless builds on macOS with the change (LuaMenu.cpp recompiled,
spring-headless linked). Building alone does not exercise the runtime path;
functional verification (lobby connecting to a multiplayer server via Chobby)
is recommended. The mechanism is straightforward: socket.lua now resolves
from the base VFS, so luaopen_socket_core plus the Lua wrapper initialise.

Provenance

Ported from e9ca2151b5 in ExaDev/RecoilEngine.

AI disclosure

Diagnosis and patch prepared with AI assistance (Claude). The change is a small,
verbatim alignment with existing CLuaUI::InitLuaSocket; reviewed and built
locally by a human.

[sprunk]

The function seems to be the same in LuaUI and LuaMenu now so should probably be extracted into /rts/Lua/LuaLibs.cpp as something like LuaLibs::OpenLuaSocket.

[tomjn]

@sprunk The shared body ends with LoadCode which is protected in CLuaHandle, so a LuaLibs::OpenLuaSocket can't call it directly without either taking the load step as a callback or replicating LoadCode's traceback/fenv handling.

As both CLuaUI and CLuaMenu derive from CLuaHandle, maybe we should put it in a CLuaHandle::InitLuaSocket so they both inherit instead?

Something like this:

// rts/Lua/LuaHandle.h  (in the protected: section, near LoadCode at line 331)
      bool InitLuaSocket(lua_State* L);

// rts/Lua/LuaHandle.cpp
bool CLuaHandle::InitLuaSocket(lua_State* L)
{
      RECOIL_DETAILED_TRACY_ZONE;
      // socket.lua ships in springcontent.sdz under LuaSocket/; load it from the
      // base VFS. A bare "socket.lua" in the default VFS never resolves, so the
      // menu/lobby's LuaSocket support failed to initialise, breaking multiplayer
      // connections from Chobby.
      const std::string filename = "LuaSocket/socket.lua";
      CFileHandler f(filename, SPRING_VFS_BASE);

      if (!f.FileExists()) {
              LOG_L(L_ERROR, "Error loading %s (file does not exist)", filename.c_str());
              return false;
      }

      LUA_OPEN_LIB(L, luaopen_socket_core);

      std::string code;
      if (!f.LoadStringData(code)) {
              LOG_L(L_ERROR, "Error loading %s", filename.c_str());
              return false;
      }

      return LoadCode(L, std::move(code), filename);
}

[sprunk]

Sounds okay. Being in LuaLibs would be ideal because that's where all the other "open lib" functions are, but if that is hard (idk, make LoadCode public and OpenLuaSocket a template?) then commonizing it elsewhere is also fine.