GTK editor hover (RichTextPopup): scrollbar click on persisted popup leaks to editor scrollbar behind

[JDonaghy]

Symptom

When the GTK editor hover popup (RichTextPopup, #214) has been clicked-to-persist and the popup has its own scrollbar visible, clicking on that scrollbar also activates the editor's scrollbar underneath the popup. Two scrollbars react to the same click.

Likely cause

The persisted-popup mode is a modal-style overlay that should consume mouse events inside its bounds before they reach the editor. Either:

1. The GTK click handler in `src/gtk/mod.rs` doesn't route through `quadraui::ModalStack` for this surface.
2. Or it does, but the popup's `ModalEntry::bounds` are smaller than the actual painted area (so the scrollbar column falls outside the modal bounds and flows through).

Scope check: editor hover popup migrated to RichTextPopup in #214; the Phase B.4 event-routing pilot (`a02eff9`) introduced `ModalStack` for the picker. Whether RichTextPopup was wired through the same dispatcher is the thing to verify.

Files

• `src/gtk/mod.rs` — mouse click handler around the editor area; check whether it consults `ModalStack` before forwarding to the editor scrollbar's gesture controller.
• `src/render.rs` — RichTextPopup adapter; verify the popup's bounds include the scrollbar column.

Surfaced by

#223 Tooltip pilot smoke test. Pre-existing — Tooltip primitive doesn't have a scrollbar.

[JDonaghy]

Refinement from smoke test of the Dialog pilot (Session 332): the scrollbar leak only reproduces when the popup is forced all the way to the right edge of the editor area. When the popup has space on the right side, scrollbar clicks land correctly within the popup. Suggests the modal-bounds clamping clips the popup's right edge to the viewport, putting the scrollbar's hit zone effectively on the editor scrollbar's hit zone. Worth checking whether the modal's ModalEntry::bounds use the popup's intended width vs the clamped-to-viewport width.