fix(ime): draw the composition on the cursor, not in the corner

[midagedev]

Summary

An IME's preedit — the text being composed, before it is committed — is drawn by the browser inside the focused element, at that element's caret. The terminal draws its cursor on a canvas, and a canvas has no caret, so nothing lines the two up on its own: the preedit and the platform's candidate window land wherever the focused input happens to sit.

Three things put that input away from the cursor:

1. focus() focused the contenteditable parent rather than the helper textarea, so the browser inserted the preedit as text nodes in the parent's own content flow — beside the canvas, not on the cursor. (handleCompositionEnd already swept those nodes back up afterwards, which is how visible the leak was.)
2. The textarea was created at left:0/top:0 and never moved.
3. The parent was left position: static, so position: absolute on the textarea resolved against whatever ancestor happened to be positioned. In a host app whose panel is relative, that puts the IME target outside the terminal entirely.

And even once the target is in the right place, the preedit inside it is invisible, because the textarea is (opacity: 0, clip-path: inset(50%)). handleCompositionUpdate was a deliberate no-op that deferred to "the browser's input method editor UI" — but there is no such UI to defer to when the input it would draw into cannot be seen.

Before / after

Same harness both times: a terminal inside a position: relative panel, cursor on the last line, composing 한글. The marked text is set through Chrome DevTools Input.imeSetComposition — the same path a platform IME takes — so the browser really renders these preedits. They are not synthetic CompositionEvents.

Before (this branch's parent commit) — the preedit is detached from the cursor:

After — it sits on the cursor cell, in the terminal's font and colors, underlined:

Why the visible preedit matters, specifically for Korean

Hangul composes within a syllable: ㄱ becomes 가 becomes 각 as you type, and only the final syllable is committed. Without a visible preedit there is nothing on screen between pressing a key and committing — you are typing blind. Chinese and Japanese at least have a candidate window to read; Korean has only the preedit itself. This is the part of #119 that positioning alone does not fix.

Changes

• lib/ime.ts (new) — ImeOverlay: keeps the textarea on the cursor cell and draws the composing text there, in the terminal's own font/colors, underlined the way platforms mark uncommitted text.
• lib/terminal.ts — focus() focuses the textarea; the parent becomes a containing block when it is otherwise static; a focus handler on the parent forwards to the textarea and is removed in dispose(); the textarea keeps a real box with a transparent caret and text instead of clip-path: inset(50%), because the platform anchors the candidate window to that box. Tracking rides the existing render loop, which already reads getCursor() every frame.
• lib/input-handler.ts — the composition handlers drive the overlay.
• lib/ime.test.ts (new) — 8 cases.

The parent keeps contenteditable: extensions like Vimium look for it. It just no longer holds focus.

The transparent caret also removes the "ghost cursor at (0,0)" from #122 — that cursor is this textarea's caret. I did not set out to fix that one; it falls out of giving the textarea a real box in the right place.

Relationship to open work — please read before reviewing

This overlaps existing work, and I would rather say so than have a reviewer find it:

• fix: Korean/CJK IME composition events not captured #120 (@hongsw) makes the same focus() → textarea change, and moves the composition listeners onto the textarea. If fix: Korean/CJK IME composition events not captured #120 lands first, that hunk of mine disappears in a rebase and the rest applies unchanged — happy to rebase on it, or to split this into positioning-only on request. fix: Korean/CJK IME composition events not captured #120 also carries a wide-character copy fix that is not in scope here.
• feat: OSC 133 shell integration, OSC 22 cursor, focus events, sync output, headless mode, WASM 1.3, Playwright E2E suite #169 (@diegosouzapw) repositions the textarea to the cursor cell as part of a much larger change, and @diegosouzapw's fork has carried that fix since [DEMO]CJK Input position issue in DEMO #97 was reported. feat: OSC 133 shell integration, OSC 22 cursor, focus events, sync output, headless mode, WASM 1.3, Playwright E2E suite #169 keeps clip-path: inset(50%) and adds no preedit rendering, so the composing text stays invisible there.

I opened this as a separate, small PR rather than pushing to either, because the visible-preedit half is not in either one and this is the part CJK users actually hit. If maintainers would rather see it folded into #120, say the word.

Fixes #122.
Addresses the composition-visibility half of #119, and #97's positioning symptom.

Credit: #119 and #120 by @hongsw are what identified the focus/listener mismatch; the repositioning idea is the same one @diegosouzapw shipped in their fork.

How this has been tested

• bun test — 380 pass / 0 fail (372 before this branch, +8 new). All four Terminal IME wiring cases were confirmed failing against the parent commit before the fix was written.
• bun run lint, bun run typecheck, bun run build (with build:wasm under Zig 0.15.2) — all clean.
• bun run fmt reports lib/selection-manager.ts, which is pre-existing: prettier --check . reports exactly the same file on main at the parent commit. I left it alone rather than mix an unrelated reformat into this diff.
• The screenshots above are Chromium only, via CDP marked text. Not tested: a real platform IME on macOS/Windows/Linux, Firefox, or Safari — I do not have a way to drive a native IME in CI, and I would value a maintainer or @hongsw trying the real thing. The positioning and visibility logic itself is platform-independent DOM, but the candidate-window placement is the platform's call and I can only show that we now hand it the right anchor.