perf(scene): draw preview/grip overlay from a separate GPU buffer

Command-preview / interim / grip-drag wires were appended into the main
wire buffer (all_wires), so every drag frame re-packed and re-uploaded the
entire batched base set — O(N) per move even though only the small overlay
changed.

Split them out: build_primitive keeps `wires` as the cached base only and
passes the overlay as a separate `preview_wires` Arc. The base keeps the
stable tile content id (no per-frame nonce), so its buffer stays resident
and is not re-uploaded during a drag. The overlay uploads to its own small
gpu_preview_wires buffer each frame and draws on top in the wire pass
(same pipeline, same order/depth). The dragged entity still renders
highlighted via its selected-path tessellation.

With the no-re-tess changes, a grip / command drag now costs a single
small overlay upload per move and nothing else.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ROADMAP.md

@@ -266,6 +266,14 @@ the batched hatch pipeline (`hatch_batched_gpu.rs`) to wires:
 At 100 k wires that collapses thousands of draw calls into one. If iced
 0.14's widget-pipeline limits allow, immediate win.
 
+**Follow-up (landed): separate overlay buffer.** Command-preview / interim /
+grip-drag wires were appended into the main wire buffer, so every drag frame
+re-uploaded the entire (batched) base set. They now ride in their own small
+per-frame `gpu_preview_wires` buffer drawn on top in the wire pass, so the
+resident base buffer stays untouched during a drag — only the tiny overlay
+re-uploads. Combined with the no-re-tess work, a grip/command drag now costs
+one small overlay upload per move, nothing else.
+
 ### 3.4 Hardware instancing for repeated block inserts
 
 When the same block defn is `INSERT`-ed N times (every door / window in