input: Anchor completion/code-action popups to the current frame's caret

[sola-ryu]

A completion popup opened by a keystroke stays where the caret was: the menu resolves its position in render() from the input's previous frame paint layout, but the caret's new position is only known after the current frame's prepaint.

This change resolves the popup position during the current frame instead of requesting a follow-up frame:

• TextElement::prepaint stashes fresh caret geometry (PrepaintCaretGeometry: cursor bounds, line height, input bounds, clamped scroll offset) in the state. Only the positioning geometry is stashed; the existing paint-time state updates are untouched.
• Popups live inside deferred(), so their prepaint runs after the input's prepaint. A new CaretAnchoredPopup element resolves the anchor there via the shared caret_popup_anchor() and builds the popup content from it — position, hitboxes, accessibility bounds, and width/layout decisions (max_width, vertical vs horizontal docs) are all consistent with the resolved position.
• Both the completion and code-action menus use the shared anchor; their duplicated origin() methods are removed.

No extra frame is requested for any input, ordinary or otherwise.

Two regression tests in crates/kit/tests/input/completions.rs:

• completion_popup_follows_caret_on_first_frame — types a character, renders exactly one frame, and asserts the popup moved right with the caret and sits at the freshly laid-out caret position (not just moved).
• ordinary_input_schedules_no_followup_frame — types in a plain input, settles, and asserts simulate_next_frame schedules nothing.

Public API

gpui-base

• PrepaintCaretGeometry (doc-hidden) — caret positioning geometry from the input's latest prepaint: cursor bounds, line height, input bounds, and the clamped scroll offset.
• InputBaseState::prepaint_caret_geometry(&self) -> Option<PrepaintCaretGeometry> (doc-hidden) — reads the stashed geometry for caret-anchored popups.

No public API changes; behavior-only fix otherwise.

---

This PR is 100% AI-generated: originally drafted with Claude on 2026-10-04, reworked per review feedback, rebased onto current main, reviewed and validated by the contributor: cargo fmt --check, cargo clippy -p gpui-base -p gpui-component --all-targets -- --deny warnings, and the input test suite (168 passed, including the two new regression tests) are all green.

[huacnlee]

This PR addresses a valid problem: a completion popup can retain the previous caret position because it reads persisted geometry before the input publishes the current frame's layout. I confirmed that GPUI's drawing-time notification does not deliver the observer notification or request the follow-up frame in this path.

However, please revise the approach before merging:

1. The next-frame notification is installed in the shared Input implementation for every geometry change, including input bounds, scroll size, caret bounds, and line height. This requests an additional frame even for ordinary inputs with no caret-anchored popup. It also leaves popup positioning dependent on a second frame rather than using the current frame's geometry.
2. The new test checks that an observer receives a notification, not that the completion popup actually follows the caret. It could pass while the popup remains incorrectly positioned.

Please resolve caret-anchored popup positioning during the current frame: make the necessary caret/input/scroll geometry available after input prepaint, and read it when the popup is positioned in deferred prepaint rather than capturing the previous position during render. Keep the change narrowly focused on positioning geometry rather than moving all of the existing paint-time state updates. Share the positioning logic between completion and code-action menus, and keep popup content, hitboxes, accessibility bounds, and width/layout decisions consistent with the resolved position.

Please add a regression test that verifies the popup follows the caret on the first rendered frame after editing, with coverage for wrapping/scrolling as appropriate, and that ordinary inputs do not acquire unnecessary follow-up frame requests.

Validation for this review: inspected the PR diff, Input and popup rendering paths, and the pinned GPUI notification/frame scheduling implementation. I did not run the tests or perform UI validation.

[sola-ryu]

Reworked per your feedback:

1. No extra frame: the on_next_frame notify is gone. The input now stashes fresh caret geometry (PrepaintCaretGeometry) during prepaint; popups live inside deferred(), so their prepaint runs after the input's prepaint and they anchor to the current frame's caret. Ordinary inputs get no follow-up frame requests.

2. Shared positioning: both menus' duplicated origin() methods are replaced by a shared caret_popup_anchor(), and both renders go through a new CaretAnchoredPopup element that resolves the anchor in its deferred prepaint and builds the popup content from it — position, hitboxes, accessibility bounds, max_width, and the vertical/horizontal docs layout are all derived from the resolved position.

3. Tests: completion_popup_follows_caret_on_first_frame types a character, renders exactly one frame, and asserts the popup sits at the freshly laid-out caret (via test-supported observation of the menu bounds, compared against the stashed geometry). ordinary_input_schedules_no_followup_frame asserts simulate_next_frame schedules nothing after typing in a plain input.

Only the positioning geometry is stashed in prepaint; the existing paint-time state updates are untouched.

[sola-ryu]

Rebased onto latest main (now includes #3410, #3411, #3413). No code changes — one import-list conflict resolved in crates/component/src/input/mod.rs (ShowCompletions from #3411 + PrepaintCaretGeometry from this PR). Verified: 181 input tests pass, clippy clean with --deny warnings, fmt clean.