fix(editor): keep dynamic dialog layout and status snapshots consistent #58

Reported symptoms and confirmed mechanism

The user observed that content-sized progress modals sometimes leave excess space below the action row, and sometimes fail to display all lines after the status text becomes longer. The reports involve both script compilation/reload and game export, so the fix must belong to reusable dialog presentation rather than one workflow.

Confirmed at the issue baseline:

• EditorModalRenderer sets a fixed styled width, an automatic height and AlwaysAutoResize for non-resizable content-sized modals.
• ImGui computes automatic window size from the previous frame's content bounds. A change from one line to multiple lines, or back, can temporarily mismatch the current text and allocated window height.
• Shared WrappedText wraps at the current available content width; progress bars and the centered action are submitted afterwards.
• Script progress fraction and status are separately published and separately read, so they are not one coherent operation snapshot.

The previous-frame sizing mechanism is confirmed. The user's persistent clipping/spacing behavior has not yet been reproduced with frame-by-frame geometry, and must not be described as fully explained by an ordinary one-frame delay. Do not assume a BGCS/native-binding defect.

Scope and owners

• Shared mechanics: Inno.Editor.ImGui/Runtime/EditorModalRenderer.cs, existing modal host and shared Widgets.
• Neutral policy: existing Inno.Editor.Core.EditorModal contract, only if a necessary contract change is demonstrated; Core must not reference ImGui or workflow implementation types.
• Message/progress snapshot producers: their existing scripting/export workflow owners.
• Callers: ScriptCompilationModal, GameExportProgressModal and other real message/status/confirmation dialog consumers identified by the audit.

This is the common layout/state problem. #57 owns Support Pack progress generation, stage reporting and tool activity. That issue should consume the common fix, not duplicate modal sizing.

Required behavior and design

1. Audit actual content-sized dialogs and their shared measurement/rendering chain. Identify message, action row, progress/details area, padding, overflow and scale ownership; do not patch by window title, modal ID or workflow.
2. Observe one immutable/coherent status snapshot per draw: operation identity, text, progress/mode and action availability come from the same state. Prevent stale updates from retired/canceled operations from appearing in a new dialog.
3. For shared message/progress layouts, derive wrapping and geometry from the same current snapshot, font, logical width and DPI/Zoom state. Determine the required current-frame layout before fixing the window bounds. Do not rely on the previous message's line count.
4. Keep text, progress/details and actions within the intended content bounds on the transition frame. Use explicit consistent padding and one overflow/scroll owner. Long errors must remain accessible within the viewport; do not solve overflow by growing beyond the display.
5. Respect intentional modal size and user-resizable policies. Do not replace every custom modal with a large fixed-height window or add unconditional empty spacing.
6. Do not invoke arbitrary extension drawing callbacks twice to measure them. Reuse existing layout/control contracts and introduce only the smallest demonstrably necessary presentation boundary.
7. Preserve modal identity, focus, input blocking, fade/minimum-visible lifetime, native scope balance and exact frame/window/context/thread ownership. Independent sessions/windows must not share mutable layout state.
8. Correct workflow labels where a substage is complete but the whole operation is not. For example, script compilation currently occupies 80% before activation/state recovery/unload verification. Communicate that distinction; do not report 100% early or weaken retirement barriers to make the UI look finished.
9. Reuse existing Core Events/Identity/lifetime facilities where applicable. Do not add a global layout cache, parallel dialog framework, compatibility facade or test-only production entry point.

Reproduction and diagnosis

Create a public-boundary native ImGui fixture that keeps a dialog open while deterministically switching among:

• One-line, two-line, many-line and empty status.
• Explicit newlines, wrapped text, long unbroken tokens, Chinese/non-ASCII and long diagnostics.
• Determinate/indeterminate progress and active/cancel-requested/completed/error states.
• Details collapsed/expanded and action availability changes.

Record current message identity, wrap width, measured content bounds, final dialog bounds and action rectangles for the transition frame and subsequent frames. Preserve an initial failing case before implementing the fix.

Low frame rate makes an ordinary layout delay more visible, but cannot excuse inaccessible content or persistent oscillation. Reproduce controlled slow frame advancement without changing production timing or adding special runtime flags.

Acceptance

• First-frame text growth/shrink and repeated alternating messages do not clip content, overlap controls, oscillate size or leave obsolete line-height gaps.
• Padding/action alignment remains consistent; deliberate visual padding is distinguished from stale allocated space.
• Text wrapping, measurement and rendering use the same width/font/scale and the same status snapshot.
• Long content is readable through the one intended scrolling region, with buttons reachable inside the viewport.
• Cover the existing independent Zoom/DPI matrix and small/reference window sizes, including narrow available width and live scale changes.
• Real native context and public input tests verify action hit rectangles, Cancel, keyboard focus, popup/modal occlusion and no input penetration.
• Opening/closing, minimum-visible/fade transitions, two sessions/windows, cancellation and extension generation retirement preserve resource ownership and original exceptions.
• Exercise actual scripting and export callers plus at least one other applicable dialog, demonstrating shared reuse without workflow branches in the renderer.
• Preserve strict reload/ALC retirement and atomic build publication; correct presentation does not hide pending or failed work.
• Measure steady and changing-content CPU/allocation costs, avoiding unbounded caches or duplicated callback work.
• Public API/XML, scripting exports where affected, project reference boundaries, design standard, Wiki and regression evidence match the final implementation.

No BGCS source/package, vendor or generated-binding changes; no global/implicit imports, IVT, private reflection or legacy fallback.

Related: #57 (Support Pack reporting), #36 (previous visual/input acceptance). This issue records an additional dynamic-content scenario not established by the earlier fixed-case acceptance.

Verified on branch / awaiting merge

Verified at 8c6694ba05f4acc5ca43e75c63f34aec2a4c45d4 in PR #60. Keep this issue open until the PR merges into master.

• Current-frame preparation/measurement, shared dialog layout and coherent operation snapshots are implemented across scripting, export, Sample Import, Shader Check and Plugin Export.
• Local acceptance passed 73 native UI cases, 12 additional hot-path cases, five export/retirement cases, Shader Check and seven isolated scripting/sample/lifecycle regressions. The 28 Zoom/DPI combinations use real native contexts with simulated display metrics; physical monitor coverage is not claimed.
• The independent FlappyBird copy completed eight workflows and 15,000 frames with orderly exit. Four dialog workloads each completed five paired 100,000-frame samples; CPU/P95 median changes remain below the agreed 10% limit and managed allocations decrease 2.2–7.6%. Earlier failed attempts remain in the evidence.
• Final-head Engine CI passed Windows x64 and macOS ARM64 Debug/native smoke, the scoped contracts/workflows, architecture and compiled Wiki checks. Windows evidence and macOS evidence contain logs, binlogs and test/Wiki results.
• Sealed local acceptance and ownership review records the local implementation, performance data and limits. This final CI confirmation supersedes its pre-CI pending status without changing the tested source.

BGCS remains 4.1.2 and unchanged. No vendor/generated binding edits, global/implicit imports, private-reflection tests or production validation bypass were introduced. Core remains neutral, ImGui owns presentation and each workflow retains state/cancellation authority. Strict ALC retirement and atomic publication remain intact.

Support Pack stage telemetry (#57), general engine performance attribution, human macOS/display experience and unrelated full Player/Browser deployment acceptance remain outside this issue. This verification does not assert that all future UI code is defect-free.