Investigate computing terrain altitude natively instead of GW::Map::QueryAltitude

[3vcloud]

Motivation

Several in-world overlays drape geometry onto the terrain by sampling the surface height per vertex. Today this goes through GW::Map::QueryAltitude (TerrainDrape::QueryAltAt → GW::Map::QueryAltitude), which is a game-side call we invoke potentially thousands of times per frame. This is the dominant cost behind the Skill Range Rings FPS collapse (#2408): a large ring is ~1000 vertices × n_planes QueryAltitude calls every frame.

It would be worth investigating whether Toolbox can compute the altitude for an arbitrary (x, y[, zplane]) point itself, from data we already have mapped, avoiding the repeated dependence on the GW implementation.

What we already have

GWCA exposes the full pathing map per zplane (GW::Map::GetPathingMap() → PathingMapArray), including:

• PathingTrapezoid — the 2D trapezoids (XTL/XTR/YT, XBL/XBR/YB) that tile each plane, plus adjacency and the XNode/YNode/SinkNode search tree (root_node) used for point location.
• PathingMap.dat_vectors and the node tree, which is exactly what a point-in-trapezoid lookup would traverse.

See Dependencies/GWCA/include/GWCA/GameEntities/Pathing.h.

Open questions to investigate

1. Where does the altitude value actually come from? The PathingTrapezoid struct is purely 2D (no z). QueryAltitude must combine the trapezoid location with a terrain height source (heightmap / plane equation / interpolation across trapezoid corners). We need to find where that z data lives and whether it's reachable from Toolbox.
2. Point location: can we reuse the exposed node search tree (root_node + X/Y nodes → SinkNode.trapezoid) to locate the containing trapezoid cheaply, rather than scanning trapezoids?
3. Interpolation: once the trapezoid (and its height data) is known, how does GW interpolate altitude within it? Match that so our values agree with the game's.
4. Correctness vs. cost: even a native implementation is per-point work; the bigger win may be caching/decimation (see Skill Range Rings: large rings cause severe FPS drops #2408). This issue is specifically about removing the hard dependency on GW::Map::QueryAltitude and enabling cheaper batched sampling.

Consumers that would benefit

• GWToolboxdll/Utils/TerrainDrape.cpp (SurfaceZ, DrapeZ, QueryAltAt) — the single choke point; all draped overlays go through here.
• Skill Range Rings (Skill Range Rings: large rings cause severe FPS drops #2408), and any future in-world draped geometry.

Related: #2408