Prompt is misplaced after an inline image is drawn by a plugin/external command (Reedline does not account for the image footprint) #1237

When a plugin (or any external program) writes an inline terminal image to stdout — iTerm2 OSC 1337 or Kitty graphics — Nushell draws the next prompt at the image's right edge, and after a repaint the prompt/input line visually overlaps or sits beside the image. The underlying text buffer is actually correct: typing still appears at the left of the next line. It looks like a Reedline/terminal repaint issue with inline images, not a cursor-position issue.

This is reproducible without any plugin, using wezterm imgcat, so it is not specific to one plugin.
charton plugin: https://github.com/wangjiawen2013/charton/blob/main/nu_plugin_charton/README.md

To Reproduce

Terminal: WezTerm on Windows (iTerm2 image protocol auto-detected).

1. Start nu.
2. Draw an inline image, e.g. with a plugin:

     open assets/data.csv | charton -g bar -x category -y amount

   (or plugin-free, with WezTerm's own tool: ^wezterm imgcat some.png)
3. Draw it a second time, or press a key to force Reedline to repaint the prompt.
4. Observe the prompt.

Expected behavior

After the image, the prompt and input line start below the image at column 0, and stay there across repaints/resizes/scroll.

Actual behavior

• The prompt is drawn at column = image width instead of column 0.
• After the next repaint (second image, or a keystroke) the prompt/input line appears over/next to the image.
• Fullscreen is unaffected; windowed terminals show it once a redraw/scroll is involved.
• The actual input position is correct — only the rendering is wrong. This is confirmed with wezterm cli get-text: the text grid shows the prompt at column 0, while the rendered screen is visually misplaced.

Environment

Additional context

• A plugin renders inline in local-socket mode (per the plugin docs, the child inherits the shell's stdout), so the image escape sequence is written straight to the terminal, bypassing Nushell/Reedline.
• WezTerm's iTerm2 image path leaves the cursor at the image's right edge and does not reset the remembered column on a bare LF; appending \b\r after the frame resets the column for the immediate prompt, but
  Reedline still misplaces it on repaint because the image's cell footprint isn't tracked.
• Suggestion: after a plugin/external command writes terminal escape sequences (especially inline images), Nushell/Reedline could re-query the cursor and repaint the prompt accounting for the image rows, or
  reserve the image footprint so later repaints stay consistent. Failing that, documenting the limitation for image-rendering plugins would help.