Built-in terminal: stray character left at the start of the input line when the shell prompt contains a wide (emoji) glyph

Summary

In the desktop app's built-in terminal pane, a stray character is left at the
start of the input line when the PowerShell prompt contains a wide (emoji)
glyph. The line that is displayed is not the line that runs: the shell receives
the correct command, but the pane shows an extra leading character in front of
it. The same prompt renders correctly in Windows Terminal.

What I see

Two consecutive commands typed in the pane, with a starship prompt whose
[python] segment is "[🐍 $virtualenv]($style) ":

The leading g and d are not in the command buffer; the error message and the
command output both prove the shell got the text without them. The stray
character looks like a leftover from the previous redraw of the input line: in
each case it matches the first character of an earlier command.

Steps to reproduce

1. Windows 11, PowerShell 7 in the desktop app's built-in terminal pane,
   starship as the prompt.

2. Create a scratch directory with a requirements.txt in it (so starship's
   python segment is shown) and a minimal config, e.g.

   add_newline = false
   format = "$directory$python$character"
   
   [directory]
   format = "[$path]($style) "
   
   [python]
   format = "[🐍 $virtualenv]($style) "
   detect_files = ["requirements.txt"]
   
   [character]
   success_symbol = "❯"
   error_symbol = "❯"
   

3. In the pane:

   $env:STARSHIP_CONFIG = '<path to the config above>'
   starship init powershell | Out-String | Invoke-Expression
   

4. Type a few short commands in a row (dir, whoami, pwd), pressing Enter
   after each. From the second command on, the input line is drawn with an
   extra character in front of it.

Removing the emoji from the prompt ("[py $virtualenv]($style) ") makes the
artifact go away, which is what points at glyph width rather than at PSReadLine
itself.

Expected

The input line shows exactly the characters that were typed, as it does in
Windows Terminal with the very same prompt configuration.

Likely cause

U+1F40D is East Asian Wide, so it occupies two cells. It looks like the pane's
renderer and the column accounting used when the input line is redrawn disagree
on that width by one cell, so each redraw starts one column off and the
previously drawn character at that column stays on screen. Any wide glyph in
the prompt should be enough to trigger it; the emoji is just the common case.

Environment

• Claude Desktop 2.2553.1, claude-code 2.1.275
• Windows 11 Home 10.0.28000
• PowerShell 7.6.6, PSReadLine 2.4.5
• starship 1.26.0
• TERM=xterm-256color, COLORTERM=truecolor, TERM_PROGRAM=claude-desktop

Workaround

Keying off TERM_PROGRAM -eq 'claude-desktop' in the PowerShell profile and
pointing STARSHIP_CONFIG at a copy of the prompt config with the emoji
replaced by plain text. It works, but it means keeping a second prompt
configuration just for this pane.

Start at the desktop app's built-in terminal pane and reproduce the issue on Windows 11 with PowerShell 7, starship, and the provided prompt configuration. Trace the input-line redraw and wide-glyph column accounting; done means consecutive commands display exactly as typed when the prompt contains the emoji, matching Windows Terminal.