feat: add Phase 20a stage identities and overlap selection

docs/guides/editor_visual_style_guide.md

@@ -22,6 +22,7 @@ The Sandbox Stage establishes a useful baseline for hierarchy, contrast, child-f
 | --- | --- | --- |
 | Sandbox Stage | SandboxTheme loads validated tokens from [sandbox_theme.json](../../sandbox_theme.json). Stage inspector controls live under [scripts/shared/stage_ui](../../scripts/shared/stage_ui/). | Use as the product reference for semantic colors, readable type, focus, action roles, and reusable theme access. |
 | Stage inspector | The approved [Stage panel UI system](../specs/stage_panel_ui_system.md) targets in-stage selected-object cards. | Do not insert StageInspectorPanel into editor inspectors by default. Borrow fitting rules and state behavior; use its components only if the layout and ownership match. |
+| Stage object names and overlap chooser | [Phase 20a](../specs/phase_20a_stage_identities_and_names_ui_ux.md) defines the name-and-Rename inspector header and the anchored **Objects here** chooser. | Reuse the rename interaction for other renameable objects; reuse the chooser shell and state tokens for similar non-modal object pickers. Follow the click-versus-drag and transform-handle priority in §4.6. Keep object-specific naming rules with the owning feature. |
 | Stage and editor dialogs | [StageDialogStyler](../../scripts/shared/stage_ui/stage_dialog_styler.gd) draws the shared confirmation card over the active scene while retaining native dialog signals. The style reads `popups.confirmation` from SandboxTheme. | Use this shared card for Prop and Stickman confirmation, recovery, and short action dialogs. Native file picker content remains native. |
 | Shared editor chrome | [EditorVisualTheme](../../scripts/shared/editor_ui/editor_visual_theme.gd) loads validated tokens from [editor_visual_theme.json](../../editor_visual_theme.json) and builds each editor's local control Theme. `EditorSelectionDropdown` and `EditorContextMenu` supply shared selection and canvas-menu styling. | Use shared semantic tokens and controls for matching editor workflows. Keep editor-specific document behavior in its owner. |
 | Prop Editor | [PropTheme](../../scripts/editors/prop/prop_theme.gd) reads [prop_theme.json](../../prop_theme.json) for material, geometry, and canvas defaults; editor chrome comes from `EditorVisualTheme`. The main scene uses split containers, a scrollable inspector, modes, and a nested Attach preview. | Keep Prop artwork/material values and canvas contrast in `PropTheme`; use shared editor tokens for chrome, inspector states, and selection dropdown styling. |
@@ -98,6 +99,7 @@ For drawing handles, keep a contrasting backing/halo where the canvas can contai
 - **Editor inspector:** favor a persistent column beside the canvas, with labeled groups and vertical scrolling. The Prop Editor already uses a split container and scrollable inspector. Separate sections with rounded cards, readable headings, colorful section icons, and concise helper copy; keep related values grouped in compact tiles. Reuse Stage's hierarchy and state clarity, but do not force the floating Stage card structure into this column.
 - **Temporary targeting step:** the Stage capture bar is for a short-lived click-on-stage task. An editor can borrow the prompt-plus-visible-Cancel contract when it has a similar temporary canvas capture step, but should not copy the bar just because it is visible in Stage.
 - **Modal dialog:** follow [Dialog Design Principles](../specs/dialog_design_principles.md). Keep a labeled **Cancel**, **Done**, or **Back** action; use one visually clear primary action; preserve the clicked control's anchor when content grows; cap height and scroll content on short viewports.
+- **Anchored object chooser:** use the non-modal chooser pattern in section 4.6 for resolving overlapping canvas targets. Keep it visually distinct from a centered dialog and from a persistent inspector.
 - **Canvas tools:** keep mode and document controls outside the draw area where possible. Put contextual handles and temporary prompts near the object only if they do not obscure the task.
 
 ### 4.2 Reuse through tokens and small components
@@ -136,6 +138,26 @@ Use the Sandbox Stage confirmation card for child-facing confirmation, recovery,
 
 Treat the card as one shared product pattern. Do not create editor-local confirmation palettes or button-role variants.
 
+### 4.5 Renameable object inspector header
+
+When a selected object has a user-editable name, show that name once in the inspector header beside the object's type icon. Put a clearly labeled **Rename** button beside it; the title itself should not be an undisclosed rename hotspot. Truncate a long title with an ellipsis and expose the full value as a tooltip. Keep the header and Rename action visible when the inspector body is collapsed.
+
+Activating **Rename** reveals a prefilled, single-line field anchored directly below the header. Provide a prominent **Done** action and a neutral **Cancel** action, both with child-sized targets. Enter commits and Escape cancels. Keep validation beside the field, explain the problem in plain language, and offer a concrete suggestion when possible. A failed rename keeps the draft visible. Cancel restores the inspector's previous expanded or collapsed state; a successful rename updates the header and any visible object labels.
+
+Use this interaction for other renameable objects when their inspector can support the same compact header and inline edit. Keep validation, uniqueness, and persistence rules in the owning feature; this visual pattern does not prescribe domain rules. Store shared header, edit, button, focus, and spacing values in the owning UI theme rather than inventing local styling for each object type.
+
+### 4.6 Anchored object chooser
+
+Use an anchored chooser when a click lands on multiple real canvas targets and the child must choose which one to act on. The Stage's **Objects here** popup is the implementation reference. It is a temporary, non-modal popup near the click, not an inspector or a centered confirmation dialog.
+
+- Resolve selection clicks and movement gestures together. When the already-selected object is one of the overlapping targets, check its rotate and resize handles first on pointer press; a handle gesture starts that transform immediately. A press on the selected object's visible body becomes a drag after movement exceeds the screen-space threshold (8 logical pixels in Stage). If released before the threshold, open the chooser and preserve the prior selection. Measure movement in screen space so zoom does not change the gesture; other canvas workflows can tune the threshold while keeping this ordering.
+
+- Give the popup a dark raised shell with a clear 2 px border, a 12–16 px corner radius, a restrained local shadow, and 12–16 px of inner space. Keep the stage visible; do not dim the canvas behind this short selection task.
+- Use full-width rows at least 44 px high, preferably around 56 px, with about 8 px between them. Keep the candidate's icon and name together. The selected candidate keeps a teal fill, cyan outline, and a visible **Selected** label; hover and keyboard focus each remain easy to distinguish from selection.
+- Keep a rounded, neutral **Cancel** button in a separate footer, at least 48 px high. Escape may also cancel. An outside click closes the chooser and is consumed so it cannot select the stage underneath.
+- Keep the clicked art visible where possible, fit the popup to safe viewport margins, and cap the list height so longer candidate lists scroll. Keep pointer hover and keyboard focus behavior equivalent when they preview a candidate.
+- Define shell, row, selected, hover, focus, badge, spacing, and Cancel values as theme tokens. The Stage implementation uses `SandboxTheme.popups.anchored_chooser`; other workflows should reuse the visual contract through their own appropriate theme owner.
+
 ## 5. Editor flows and state maps
 
 The following maps describe the current interaction architecture at a level useful for future visual work. They are not proposed additions to file formats.