[h4rk8s]

macOS can request firstRectForCharacterRange: immediately after setMarkedText:, before another paint. Both PromptInput and LoginInput convert the range against current text but look it up in the previous frame's layout. Growing a composition past that layout returns None; GPUI then returns a zero rectangle, allowing the IME candidate window to fall back away from the insertion point.

Compute IME bounds from the current display text using the font, line height and wrapping width captured during paint. A small shared helper in jcode-desktop-ui-core handles both inputs; login geometry only shapes masking bullets. Range rectangles stay on the first visual line. This does not change composition selection or commit behavior.

Related to #6 as a separate IME follow-up: that issue fixed composition-relative UTF-16 selection and a crash. This change addresses geometry between edits and paint. It does not change GPUI, runtime dependencies, or UI scaling.

Validation on macOS ARM64:

• New composer and masked-input regressions query bounds after growing and shrinking preedit without painting in between. Both fail with the original handlers and pass with this change; the composer case includes a CJK/emoji prefix and a subsequent commit.
• Shared geometry coverage checks empty text, a translated window origin, explicit newlines and wrapping. A composer regression also compares every caret against the painted layout across CJK/emoji, soft wraps and a trailing empty line.
• cargo test --workspace --no-fail-fast: 1,821 passed, 2 failed, 13 ignored. Both failures also reproduce on unmodified 39b645f: terminal_eof_waits_for_descendants_and_buffered_tail and native_mermaid_tall_diagram_fits_shared_viewport_without_clipping.

Tested against Desktop 39b645f, pinned GPUI be875c5, and sibling Jcode 48aa83e. Native candidate-window verification with EchoType is still pending; the automated reproduction covers the synchronous handler sequence, not a live IME session.