fix(server/state): don't insert into the world grid map under a shared lock

[Syxless]

Goal of this PR

While reading the relevance pass in ServerGameState::Tick I noticed it resolves the world grid differently from every other place that touches m_worldGrids:

std::shared_lock _(m_worldGridsMutex);
const auto& grid = m_worldGrids[selfBucket];

Everything else uses find(). operator[] on a std::map inserts when the key is missing, and here that happens while holding only the reader side of the lock, racing any concurrent reader of the map. The key can actually be missing: UpdateWorldGrid creates grids at the start of the tick, but a routing bucket change from another thread (or a player entity appearing mid tick) leaves the pass looking at a bucket that has no grid yet.

The inserted entry is also a default constructed null unique_ptr, and since UpdateWorldGrid only creates a grid when find() fails, it keeps finding the null entry and bailing on its if (!grid) check. From then on nobody in that bucket gets world grid ownership until the bucket empties out.

How is this PR achieving the goal

Resolving the grid once per client with find() before the entity loop, like the other call sites do. This is safe because grids are only created and erased in UpdateWorldGrid, which runs earlier in the same tick on the same thread. A missing grid now just means no world grid relevance for that pass, which is what the next tick would produce anyway, instead of poisoning the bucket.

This also removes a shared_mutex acquisition and a map walk per entity per client from the pass.

This PR applies to the following area(s)

Server, OneSync

Successfully tested on

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

[FabianTerhorst]

Hi, both emplace and erase of the world grid happens inside the tick. Please provide an scenario where emplace or erase of the world grid happens outside.

[Syxless]

Hello! The emplace and erase in UpdateWorldGrid are fine, the issue is that operator[] in the relevance pass is itself an emplace when the bucket is missing, and readers of the map exist outside the sync thread.

SET_PLAYER_ROUTING_BUCKET calls ClearClientFromWorldGrid directly on the script runtime thread (unlike the drop path, which marshals HandleClientDrop onto the sync thread via gscomms_execute_callback_on_sync_thread). That does m_worldGrids.find() under a shared_lock, plus another in SendWorldGrid. The same native also sets clientData->routingBucket with no ordering against the tick, so the relevance pass can see a bucket with no grid and operator[] inserts into the tree under the reader lock while the script thread's find() walks it. Two shared locks do not exclude each other.

Even without the race, the inserted entry is a null unique_ptr. UpdateWorldGrid only emplaces when find() fails, so it keeps hitting its if (!grid) check and the bucket never gets a real grid for as long as it keeps clients.