feat(tui): add compact image paste placeholders

[onychen]

问题

关联 #413。

在 TUI 中粘贴图片时，输入框会显示冗长的临时文件路径，影响提示词的阅读和编辑，多图场景下尤其明显。

价值

• 使用紧凑的 [Image #N] 展示粘贴的图片。
• 支持原子删除图片占位符。
• 用户消息保留占位符，同时向模型传递原生图片内容。
• 删除图片后保持编号稳定且符合直觉。
• 不影响普通文本、文件路径及手动输入的占位符。

实现方案

• 新增独立的图片粘贴编辑器层，在不修改 Pi 原生编辑器实现的情况下拦截图片粘贴和删除操作。
• 仅识别 Pi 在系统临时目录中生成的剪贴板图片，普通文件路径仍按原有文本逻辑处理。
• 粘贴图片时，将临时文件路径替换为 [Image #N]，并在当前草稿中维护占位符与图片文件的对应关系。
• 删除键命中占位符任意位置时，整块删除对应的 [Image #N]，同时释放关联的临时图片。
• 多图编号根据当前草稿中的有效占位符计算：
  • 删除末尾图片后，新图片可以复用该编号；
  • 删除前面的图片时，保留后续图片的原编号，避免顺序倒置。
• 提交消息时，将草稿附件转移到待提交状态，避免编辑器清空或排队提交时提前删除图片。
• Alt+Enter 在原生按键提交边界转移附件所有权，不依赖定时器与 input handler 的执行速度。
• 待提交附件按提交顺序及完整原始文本消费，不允许后续消息仅凭重复占位符认领旧图片。
• 自动压缩重试通过 steer/followUp 绕过 input 时，显式释放对应的待提交附件。
• 在 Pi 原生 input 事件中读取图片并生成 ImageContent，与已有图片载荷合并后交给模型。
• 提交后的文本继续保留 [Image #N]，确保用户侧消息与输入时的内容一致。
• 如果图片读取失败，则移除对应的无效占位符并向用户显示警告，不向模型发送损坏的图片数据。
• 重复或被修改的占位符不再视为有效图片引用，避免一个占位符错误关联多个图片。
• 在占位符删除、提交失败、图片消费完成及会话结束时清理临时文件，避免资源泄漏。

验证

• 覆盖图片提交、原子删除、多图输入、编号复用、排队提交、读取失败和临时文件清理。
• 相关测试全部通过：13 项通过。
• 类型检查、Lint、相关文件格式检查及 Diff 检查通过。
• 手动验证提交后的用户消息保留 [Image #1]，模型能够正常读取图片。

影响

改动仅影响 TUI 交互式图片粘贴。

已知限制：Pi 在会话压缩期间排队的消息可能绕过原生 input 事件，仅保留文本。该问题需要进一步讨论，因此暂不关闭 #413。

[tt-a1i]

Reviewed the current head 9c7f9ba. The compact placeholders and atomic deletion address a useful TUI problem, but attachment ownership still breaks across submission paths. Please address the two inline findings before merging.

Validation: the 11 image-paste/editor-layer tests pass locally, and all three required CI jobs are green. Additional minimal reproductions using Pi 0.85.1's actual InteractiveMode.flushCompactionQueue and ExtensionRunner.emitInput methods reproduce both findings. These are programmatic lifecycle reproductions, not visual TUI acceptance or live provider calls.

[tt-a1i]

Reviewed at head bc2739f.

Standards

[P1] Image ownership is inferred only from the OS temp directory, a pi-clipboard filename pattern, and statSync(). statSync follows symlinks, and the later read/delete has a check-to-use race. The extension can therefore claim and remove a matching file without runtime-proven ownership. Please use a Pi-provided attachment handle, or copy into an OpenPI-owned directory and validate identity with no-follow, bounded I/O.

[P1] The 481-line editor layer depends on several private lifecycle details at once: onSubmit wrapping, raw Alt+Enter handling, setText cleanup timing, input ordering, and compaction retry behavior. Pi 0.85.1 still exposes no stable attachment/submission seam, so upgrades can silently break ownership. This should be reduced around an explicit Pi-native attachment/submission boundary rather than duplicating InteractiveMode lifecycle assumptions.

[P2] The input handler performs unbounded synchronous readFileSync plus base64 conversion. A large clipboard file can block the TUI and amplify memory use. Add a size limit and bounded asynchronous reading after identity validation.

Spec

[P1] Successful compaction with multiple queued submissions is still unsafe. Every submission enters pending, but after normal compaction only the first queued message goes through prompt/input; later messages use steer/followUp and bypass the input transform. Their images are neither sent nor promptly cleaned, and a later identical text can consume an old FIFO submission. The existing test covers only one willRetry=true submission, not successful compaction with multiple queued submissions or repeated identical text.

The Alt+Enter cleanup race from the previous review is fixed, but attachment ownership across compaction remains incomplete. Please add the missing lifecycle evidence and resolve the current main conflict before requesting re-review.