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.

Use the linked OSC 133 semantic-prompts specification as the protocol reference. Locate the CLI rendering paths for user prompts, reasoning or tool output, final answers, and turn completion, then trace where each boundary is emitted. Done means the listed markers appear at those boundaries, unsupported terminals remain unchanged, and the Windows Terminal, VS Code terminal, and iTerm2 workflows are verified.

Rédigé par le modèle d'indexation à partir du texte de l'issue.