re: REGN is excluded as the wave scheduler -- it is a navmesh

The original reason for investigating REGN was that a mission's enemy count
rises and falls, so a scheduler with parameters must exist somewhere, and a
per-map uniform grid is what such a thing would be indexed by.

Now that it is decoded that reasoning is answered: REGN is a tetrahedral
navigation mesh -- vertices, faces carrying plane equations and adjacency,
tetrahedra with portal costs between face pairs, and a grid indexing which tets
fall in each cell. Every section is accounted for by that structure, and there is
no time field, no unit reference and no trigger anywhere in it.

So the wave-scheduler search should treat REGN as excluded rather than unread.
The page's original hedge was right to keep the reading provisional, but the
reasoning it hedged was a guess from shape, and the shape belonged to
pathfinding -- which is what pointed the whole investigation here.

The arrival timetable in Route_S<NN>.tbl, keyframed per squadron per phase with
t in seconds, remains the only located part of the mechanism.

docs/re/BACKLOG.md

@@ -337,6 +337,12 @@ search cannot find a *schedule*.
 
 **Places searched so far:**
 
+* ❌ **`REGN` is EXCLUDED as the wave scheduler (2026-08-26)** — it is a
+  tetrahedral navigation mesh (vertices, faces with planes and adjacency,
+  tetrahedra with portal costs, a grid indexing which tets fall in each cell).
+  Every section is accounted for; there is no time field, no unit reference and
+  no trigger anywhere in it. It was chased here because "a scheduler would be
+  indexed by a grid" — a guess from shape, and the shape was pathfinding.
 * ✅ **`hidden/MiscBin.pak` — new to the corpus.** 11 `REGN` + 11 `MCOL` objects,
   none name-resolved. `REGN`'s header is now decoded: a per-map **uniform spatial
   grid** (bbox, cell size, 5³ or 10³ cells), self-checked 11/11. Its four data