The value field stops being a window, and now takes what is typed

Rebases the in-canvas work onto cad-mainline and finishes it. The field is drawn
by ImGui inside the GL canvas instead of being a borderless top-level wxFrame.

WHY THE FLOATING FRAME COULD NOT BE FIXED. Whether a borderless top-level may hold
the keyboard is the window manager's decision, and it differs per desktop: openbox
grants it, mutter refuses it, macOS denies key status outright. Seven workarounds
fought that and one cost a macOS regression. Drawn inside the canvas there is no
second top-level for anyone to refuse, so the question is never asked. The field is
fed exactly like every other ImGui widget in the app — GLCanvas3D::on_char ->
ImGuiWrapper::update_key_data -> io.AddInputCharacter.

MEASURED, on behemoth: the click-edit ladder holds 28 checks — Line, Rectangle,
Circle, Slot, Polygon, Ellipse, Arc, and click-to-edit on a placed dimension label
— typing with NO click into the field first, committed == typed != prefill every
time, and 27 [UX] imgui_char lines showing the characters arriving.

WHAT WAS ACTUALLY WRONG. Not the field. The belief that "characters never reach the
ImGui InputText" came from the harness: the ladder was delivering keys with
`xdotool type --window` (XSendEvent), which GTK discards, so no build of any kind
could have received them. The new probe in ImGuiWrapper::update_key_data — the one
place ImGui is ever handed a character — is what separated that from a real defect,
and it stays, because a canvas-side probe provably cannot answer the question:
GLCanvas3D::on_char is bound later than any constructor-time probe, wx runs handlers
in reverse bind order, and on_char returns without Skip(), so such a probe is silent
whether or not the key arrived. A day was lost reading that silence as evidence.

Also drops DesignPanel's content-based forwarder and DesignCanvas::inline_type_char.
They were the right rule for a field that could not be focused; with the field
inside the canvas there is nothing to forward, and keeping them would have masked
whether the normal path works.

STILL UNVERIFIED: behaviour under mutter itself. Neither focus-stealing-prevention
WM available here survives long enough to judge — metacity SEGVs ~20s in and xfwm4
dies with BadWindow on SetInputFocus, both before the sketch opens and both
unrelated to this field. The design's claim is structural rather than measured: no
second top-level means no focus to refuse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA

src/slic3r/GUI/CAD/DesignPanel.cpp

@@ -4212,25 +4212,11 @@ DesignPanel::DesignPanel(wxWindow* parent)
                 m_viewport->inline_commit();
                 return;
             }
-            // THE ARBITER. Route by what the key IS, not by who the window manager focused.
-            //
-            // This is FreeCAD's rule, from Sketcher's DrawSketchKeyboardManager::
-            // detectKeyboardEventHandlingMode: a digit, a sign, a decimal separator or a
-            // Backspace/Delete is unambiguously meant for the number the user is entering; a
-            // letter is unambiguously a tool shortcut; Enter/Tab hand control back to the view.
-            // FreeCAD never queries focus anywhere in that decision, and that is precisely why
-            // its sketcher behaves the same on every desktop.
-            //
-            // Ours asked "who has focus?" instead — a question whose answer is the window
-            // manager's opinion. openbox grants this borderless top-level the keyboard, mutter
-            // refuses it, so the same binary took typed values on one machine and silently
-            // committed the pre-filled as-drawn number on another. Seven workarounds fought that
-            // and one of them cost a macOS regression. The question was wrong, not the answers.
-            //
-            // The has_focus() guard above keeps this from double-typing where the toolkit DID
-            // give the field the keyboard: there the field's own binding will get the key too.
-            if (!ctrl && m_viewport->inline_type_char(key))
-                return;
+            // NO forwarding here any more. The field is drawn INSIDE the GL canvas now, so it
+            // is fed the way every other ImGui widget in this app is fed: GLCanvas3D::on_char ->
+            // ImGuiWrapper::update_key_data -> io.AddInputCharacter. Re-adding a panel-side
+            // forwarder would also mask whether that path works, which is exactly what is being
+            // measured.
             // Esc is NOT special-cased here any more: escape() routes it, and the open field is
             // exactly what CadLevel::Transient means, so it closes the field and stops there.
         }