fix(terrain): keep a batch's warm points when its own fetches evict them

A warm entry could be evicted by the same call's later fetches and then
reported unresolved. The call now remembers warm hits as it does fetched ones.
Moves the batch LRU test beside the existing cache tests and folds the docs
note into the section's eviction paragraph.

docs/CURRENT-STATE.md

@@ -1192,19 +1192,17 @@ The browser layers and their rendering remain in their existing modules.
 
 ## Terrain height cache bound
 
-Warm batch lookups also promote their cached entries in the least-recently-used eviction order.
-
 The client terrain-height resolver's in-memory cache is bounded at 20 000
 entries (`DEFAULT_MAX_CACHE_ENTRIES`, overridable per instance through
 `createTerrainHeights({ maxCacheEntries })`). Coordinate rounding makes repeated
 visits to one place share a key but does not bound how many distinct places a
 session visits, and the cache previously had no eviction, so a long session
 retained every coordinate it ever resolved. Eviction is least-recently-used:
-a consumer read promotes its entry, so the cell being watched is not dropped for
-having been resolved early. The bound sits far above a city-scale session, so
+a consumer read, including a warm hit in a batch lookup, promotes its entry, so
+the cell being watched is not dropped for having been resolved early. The bound sits far above a city-scale session, so
 normal use never evicts and issues no additional proxy requests. A batch's
-results are assembled from what that call resolved, so eviction during a large
-batch cannot report a just-resolved point as unresolved. Re:Earth and
+results are assembled from what that call resolved or found warm, so eviction
+during a large batch cannot report one of its points as unresolved. Re:Earth and
 geoid-fallback entry semantics, the fallback cooldown and the abort-time flush
 are unchanged.