fix: player-anchored events never got zone-specific resources

SelectSiteForPlayer() tries to anchor an event on a live player's
current position FIRST (BuildEligibleSiteFromPlayer ->
BuildSiteFromAnchor), only falling back to a random pick from _sites
when no eligible player is available. Since there is almost always
an eligible player online, this is the common path in practice --
but BuildSiteFromAnchor only reads the player's live zone/area IDs
from the world state; it has no access to the NodeEntries/
BonusEntries that BuildSites() parsed from GoldRush.ZonePool into
_sites. Every player-anchored event therefore got an empty
NodeEntries/BonusEntries regardless of ZonePool configuration, and
SpawnHotspot()'s (correct, intentional) fallback-to-global-pool logic
silently kicked in every time.

This is why testing in Un'Goro Crater after the v2 zone-resources
feature shipped still produced Titanium Vein and Northrend herbs --
the module correctly identified the player's zone as Un'Goro
(ZoneId/ZoneLabel were right), it just never looked up Un'Goro's
configured resource pool to attach it to that site.

Fix: after building the site from the player's live position, look
up a matching entry in _sites by ZoneId and inherit its NodeEntries/
BonusEntries. A zone that's an eligible anchor but has no configured
entry in _sites still correctly falls through to the global pool --
that fallback path was never the problem, only the missing lookup
for zones that ARE configured.

src/GoldRush.cpp

@@ -487,7 +487,29 @@ private:
         if (!IsEligibleAnchor(player))
             return {};
 
-        return BuildSiteFromAnchor(player);
+        GoldRushSite site = BuildSiteFromAnchor(player);
+
+        // BuildSiteFromAnchor only knows the player's live zone/area IDs -- it has
+        // no access to the per-zone NodeEntries/BonusEntries parsed from
+        // GoldRush.ZonePool into _sites. SelectSiteForPlayer() tries a player
+        // anchor FIRST and only falls back to picking randomly from _sites when no
+        // eligible player is available, so without this lookup, the common case
+        // (a live player standing in a configured zone) silently lost its
+        // zone-specific resources and fell back to the global pool every time --
+        // exactly the bug reported after the v2 zone-resources feature shipped:
+        // events kept spawning the default Northrend-flavored global pool
+        // regardless of which zone they were actually anchored in.
+        for (GoldRushSite const& configured : _sites)
+        {
+            if (configured.ZoneId == site.ZoneId)
+            {
+                site.NodeEntries = configured.NodeEntries;
+                site.BonusEntries = configured.BonusEntries;
+                break;
+            }
+        }
+
+        return site;
     }
 
     std::vector<GoldRushSite> BuildSites(std::string const& zones) const