Add new networking

[erwan-joly]

No description provided.

General fix approach: Do not let a raw user-provided id determine whether the sensitive check _authCodeService.IsReadyForAuth is executed or influence the outcome on its own. Instead, base the decision on values that are either: (1) already validated via server-side state (for example, an auth code looked up from storage) or (2) protected by an authentication mechanism. At minimum, validate or normalize id into a well-defined, server-side verified account identifier before passing it to IsReadyForAuth, or remove id from this path entirely.

Best concrete fix for this snippet without changing external behavior more than necessary:

1. In AuthHub.GetAwaitingConnectionAsync, in the "gfmode" branch, stop using the raw id parameter to call _authCodeService.IsReadyForAuth.
2. Instead, require that the "gfmode" path also provide a server-generated token (auth code) and resolve that code to a username using _authCodeService.GetAccountByAuthCode, just like the non-"gfmode" branch does. Once a valid username is obtained, use that username when calling _authCodeService.IsReadyForAuth.
3. If the token is missing or invalid, or the username is not found, return "false" (or null) rather than allowing a bypass.
4. This keeps the overall contract of GetAwaitingConnectionAsync (it still returns "true"/"false"/username) while ensuring the sensitive readiness check always depends on server-side state derived from an auth code, not on a user-chosen ID string.

Because we cannot change outside methods or controllers significantly, we will:

• Keep the method signature of GetAwaitingConnectionAsync.
• Modify only the "gfmode" branch (where token == "thisisgfmode").
• In that branch, require that id actually be an auth code (the same format as the normal token case), convert it using HexStringToString, resolve it to a username with _authCodeService.GetAccountByAuthCode, and base IsReadyForAuth on that username instead of on id.

This stays within the shown files and uses only existing services.

---

In general, to fix generic catch clauses, you should catch the specific exceptions you expect and handle them appropriately, letting truly unexpected exceptions surface or at least be clearly distinguished. In this context, the most relevant specific exception type is OperationCanceledException (or TaskCanceledException), which is standard in asynchronous operations initiated by Task.Run and potentially by the handlers themselves. Treating cancellation as an error and logging it at error level is misleading and noisy.

The best fix that does not change existing core functionality is:

• Add a dedicated catch (OperationCanceledException) block before the general catch (Exception ex).
• In that block, either do nothing or log a debug/verbose message indicating that message handling was canceled.
• Keep the existing generic catch (Exception ex) as a last‑resort safety net to log unexpected failures, preserving current robustness.

All changes occur in src/NosCore.GameObject/Services/EventLoaderService/Handlers/ChannelCommunicationRunner.cs, inside the OnMessageReceived method’s Task.Run body, replacing the single generic catch with two ordered catch blocks. No new imports are required; OperationCanceledException is in System, which is already imported.