Emit OSC 133 shell-integration sequences so terminals can navigate to previous prompts and to the final-answer line

### Describe the feature or problem you'd like to solve

Two related scrollback problems:

1. After a long assistant turn (reasoning, multiple tool calls, lots of output), my last `>` input prompt is buried far above. Finding it means scrolling by hand.
2. When the **final answer** itself is longer than one screen, I want to scroll to the start of the answer text, not the start of the turn. The turn starts with reasoning and tool output I don't need to re-read. I want the line with the "blue dot" / final assistant message.

The terminal has no idea where these boundaries are. The CLI does, because it renders the glyphs.

### Proposed solution

Emit [OSC 133 semantic-prompt sequences](https://gitlab.freedesktop.org/Per_Bothner/specifications/-/blob/master/proposals/semantic-prompts.md) at two anchor points per turn, so every modern terminal's built-in "scroll to previous/next prompt" feature works without any new CLI keybindings.

Anchor points and sequences:

| Escape | Emit immediately before | Purpose |
|---|---|---|
| `\e]133;A;role=user-prompt\e\\` | The `>` input prompt | Anchor: user's last prompt |
| `\e]133;B\e\\` | First character after submit | Turn boundary (no nav role) |
| `\e]133;C\e\\` | First reasoning/tool-call line | (Optional) Anchor for full turn start |
| `\e]133;A;role=assistant-answer\e\\` | First character of the final assistant message (the "blue dot" line) | **Anchor: start of the actual answer** |
| `\e]133;D;\e\\` | End of turn | Turn complete |

The `role=` parameter is per-spec extensibility. Terminals that don't understand it treat the sequence as a generic mark, which is exactly what we want for navigation. Future terminal features can filter by role if useful.

### Why two anchors per turn

A long turn looks like:

```
> user prompt <- anchor A
reasoning line 1
reasoning line 2
tool call: bash
tool output (50 lines)
tool call: edit
...
* final answer line 1 <- anchor B (the blue dot)
final answer continues
...
> next user prompt <- anchor A
```

With both anchors present, `Ctrl+Shift+Up` from an empty input lands first on the blue dot (start of the final answer). Press again to land on the user prompt above. Press again to step back to the previous final answer. This is the navigation pattern users actually want when reviewing what the assistant said.

### Terminal support out of the box

- Windows Terminal: `Ctrl+Shift+Up` / `Ctrl+Shift+Down`. [Docs](https://learn.microsoft.com/en-us/windows/terminal/tutorials/shell-integration).
- VS Code integrated terminal: same key combo plus sticky-scroll showing the most recent prompt.
- iTerm2: `Cmd+Up` / `Cmd+Down`.
- WezTerm, kitty: configurable mark-jump bindings.

Terminals without OSC 133 support ignore the bytes silently. Zero-cost fallback.

### Example workflows

- Long turn with 15 tool calls. Press `Ctrl+Shift+Up` once: land on the blue-dot line. The final answer is right there. No scrolling, no skipping reasoning by eye.
- Answer is two screens long. From the bottom, one `Ctrl+Shift+Up` takes me to the first line of the answer.
- VS Code "command navigation" overlay starts working automatically across the conversation.

### Additional context

- Spec: https://gitlab.freedesktop.org/Per_Bothner/specifications/-/blob/master/proposals/semantic-prompts.md
- Implemented by `zsh`, `fish`, `starship`, `nushell` already.
- Related but distinct: #2038 (in-conversation bookmarking for content recall), #1786 (input-bar history nav), #2369 / #2205 (alt-screen scrolling issues).

### Optional add-on for non-OSC-133 terminals

In-app keybinds (`Alt+Up` / `Alt+Down` to jump between turn boundaries inside the CLI's rendered view) would cover the small remaining set of terminals. Not blocking; OSC 133 alone solves it for the majority.

### Acceptance criteria

- [ ] `OSC 133;A;role=user-prompt` emitted at the start of each user input prompt.
- [ ] `OSC 133;A;role=assistant-answer` emitted at the start of the final assistant message (the "blue dot" line).
- [ ] `OSC 133;B`, `133;C`, `133;D` emitted at standard positions for terminals that use them.
- [ ] Verified in Windows Terminal: `Ctrl+Shift+Up` cycles user prompts AND final-answer starts.
- [ ] Verified in VS Code terminal and iTerm2.
- [ ] No visual or behaviour regression in terminals that don't recognise OSC 133.

使用連結的 OSC 133 semantic-prompts specification 作為協定參考。找出用於呈現使用者提示、reasoning 或工具輸出、最終答案以及回合完成狀態的 CLI 路徑，然後追蹤每個邊界在哪裡發出。完成的標準是：列出的標記出現在這些邊界處、不支援的終端機維持不變，並且 Windows Terminal、VS Code terminal 和 iTerm2 的工作流程已完成驗證。

由索引模型根據 Issue 內容生成。