Function planInstancedOrdering

Keep the permutation, repair it over a changed count, append a suffix and hold the draw, or seed a grown geometry's held draw.

• Same buffers, same count: preserveOrdering — a permutation of [0, count) is a strictly-no-worse prior than storage order for the frame or more until the re-sort depthSort.noteCommit dispatches lands.
• Same buffers, CHANGED count: repairFromCount rebuilds the permutation over the new population instead of falling back to storage order. It is the branch a timelapse takes: an nD re-slice changes the resident count at almost every step, and storage order drew one unsorted frame per timepoint (#2290). Measured on the cloud demo at a frozen camera pose, as the fraction of sampled element pairs composited in correct back-to-front order: storage order 0.617, repaired 0.858, a real sort 1.000. "Same buffers" needs all three: committed data (a node's first commit after LOD demotion no longer vouches for its retained ordering), no attribute rebuild, and the same geometry (pool best-fit reuse can hand a node ANOTHER node's permutation over a different count).
• An EXTENSION — a larger count whose prefix lineage is the data committed here, which proves same generation (a view change resets the lineage), a genuine extension, and that the GPU still holds that parent — on the same buffers with a reusable prefix: fromInstance. The append fast path uploads only the suffix and holds the draw on the drawn prefix.
• Any other extension (a pool GROW — every ladder rung that doubles crosses the pool's 1.5x capacity headroom — or a prefix that must be rewritten): the same lineage proof makes the previous geometry's DRAWN permutation an exact ordering of a grown geometry's prefix, so it is handed over as seedOrdering and the draw is held on it instead of showing the grown node in storage order. (On the same geometry there is no seed: the rewrite repairs from the previous count instead.)