U+23FA (⏺) ambiguous-width character causes cursor misalignment in Claude Code UI

### Checklist

- [x] Using latest version on the [App Store](http://itunes.apple.com/app/id1156707581)
- [x] Read the [docs](http://blink.sh/docs/)
- [x] Searched for [existing GitHub issues](https://github.com/blinksh/blink/issues)

### Configuration

- Blink Shell 18.5
- iPadOS 26
- iPad Pro 11-inch M4
- Connected via SSH to Mac Studio
- Running Claude Code in the remote session
- Font tested: Pragmata Pro (default), JetBrains Mono Nerd Font — issue persists with both
- TERM: xterm-256color

### Describe the bug

Claude Code’s default UI uses U+23FA (⏺ BLACK CIRCLE FOR RECORD) as a status indicator in its terminal interface. This character is classified as **East Asian Ambiguous** width in Unicode (UAX #11), meaning the terminal must decide whether to treat it as 1 or 2 cells wide.

Blink’s hterm rendering engine appears to calculate a different width for this character than Claude Code expects, causing a persistent cursor misalignment artifact — the character renders as a “half disc” and subsequent text on the line is shifted. This is purely cosmetic but is visible during every interaction with Claude Code.

**Root cause:** hterm does not expose a user-configurable setting for ambiguous-width character handling (unlike iTerm2’s “Treat ambiguous-width characters as wide” toggle, or similar options in mintty and Apple Terminal.app). The width is determined by hterm’s internal `wcwidth` table, and there is no way for users to override it.

**Steps to reproduce:**

1. Open Blink Shell and connect via SSH to a remote machine
1. Run Claude Code (`claude` CLI)
1. Observe the ⏺ (U+23FA) status indicator in Claude Code’s UI
1. The character renders incorrectly — appears as a half-width glyph with subsequent text misaligned

**Expected behavior:**

The ⏺ character should render at a consistent width that matches the cursor positioning assumed by the application, with no visual artifacts or text misalignment.

**What I’ve tried:**

- Switching fonts (Pragmata Pro → JetBrains Mono Nerd Font) — no change, confirming the issue is at the hterm width-calculation layer, not glyph rendering
- Searched for an ambiguous-width character setting in Blink — none exists
- The only current workaround is to avoid applications that use ambiguous-width Unicode characters in their TUI, which is not practical

**Additional context:**

This is related to the broader class of Unicode width issues previously reported in Blink (#498 double-width glyphs, #703 Powerline symbol sizing, #472 Unicode prompt characters). The v18.4.0 release notes specifically mention Mosh UTF-8 handling improvements for Claude — this issue is in the same vein.

Start with the hterm terminal rendering path and its internal wcwidth table, then reproduce the issue by running Claude Code over SSH and observing U+23FA. Done means the character and following text remain consistently aligned, with the ambiguous-width behavior covered by a regression test or equivalent verification.

Written by the indexing model from the issue text.