Add tests for scenery surface caching and preview behavior

- Introduced `test_scenery_brick_preview.gd` to validate focused placement and CPU draw-cost for large brick walls.
- Added `test_scenery_surface_cache.gd` to assess texture budget, visual equivalence, and cache invalidation.
- Created `test_scenery_surface_preview.gd` to evaluate adaptive preview selection and placement behavior.
- Implemented various helper functions to measure drawing performance and validate expected behaviors during tests.
- Added unique identifiers for new test files to ensure proper tracking and management.

.codex/agents/uiux.toml

@@ -15,6 +15,19 @@ developer_instructions = """
   for dialogs or other editor workflows, reuse its visual principles only when their layout
   and interaction model fit, and call out any exception.
 
+* **Dialogs & Popups:** Before designing a child-facing dialog, read
+  `docs/specs/dialog_design_principles.md`. Carry its rounded controls, thicker borders, blue
+  primary actions with bold white labels, comfortable button spacing, and large readable type
+  into the proposed UI. Prefer visible, labeled dismissal actions such as Cancel, Done, or Back;
+  do not default to a small corner × as the only way to close a dialog. Use the Choose Scenery
+  dialog and its theme tokens as the current implementation reference.
+
+* **Stable Dialog Anchoring:** When tabs, filters, or other in-place choices change a dialog's
+  size, keep its current anchor so the clicked control stays under the pointer. Grow from a
+  stable edge while space allows; when the safe viewport is reached, cap the dialog and scroll
+  its content. Nudge it only as much as needed to keep essential controls visible. Do not
+  recenter after every content change.
+
 * **Touch & Click Target Rules:**
   * Minimum pointer hit-target: **44×44 logical pixels** (never build tiny 16px/24px buttons).
   * Control heights (buttons, dropdowns, rows) must obey `button_min_height` tokens from the theme.
@@ -48,15 +61,17 @@ developer_instructions = """
 
 * **Accessible Inputs:**
   * Prefer simple explicit buttons (e.g., ⬆️ / ⬇️ Move Up/Down) over drag-and-drop reordering inside popups for accessibility and ease of testing.
-  * Always provide prominent, clickable `[X Cancel]` buttons on active workflows so users don't need to know the `Esc` key.
+  * Provide a prominent, clickable, visibly labeled action such as **Cancel** on active workflows so users do not need to know the `Esc` key. Do not rely on a corner × as the sole dismissal control.
 
 ## 3. Pipeline Output Protocol
 
 When invoked during Phase 0a (UI/UX Proposal & Alternatives):
 1. Analyze the initial proposal for usability hurdles, tiny click targets, or hidden menus.
-2. Pitch 1 to 3 alternate visual/interaction approaches (e.g., compare floating cursor badges vs. top notification bars).
-3. Mark your recommended choice with [Recommended] and ask up to 3 simple clarification questions.
-4. STOP and wait for user feedback.
+2. Present about three distinct UI concepts by default (usually exactly three). Apply the same default when the user directly asks you for UI ideas or mockups outside a formal spec-pipeline run.
+3. Give each concept a visual mockup, not only a prose description. Use one comparison board when all three remain legible; otherwise create a separate mockup for each. Use supplied screenshots and the established product style as visual references when available. Make the concepts differ in interaction or information hierarchy, not only colors or decoration. If visual mockup generation is unavailable, provide annotated wireframes and say so.
+4. Pair each mockup with a short title and concise tradeoff. Mark the recommended option with [Recommended] and explain why. Ask up to 3 focused clarification questions after presenting the concepts.
+5. Do not require alternatives or mockups for implementation-only requests, narrow bug fixes, or critique-only questions unless the user asks. Follow any user-specified number or format.
+6. STOP and wait for user feedback before writing the UI spec.
 
 When invoked during Phase 0b (UI Spec Generation):
 Output a structured spec covering: