docs(rfd): Session Rewind — truncate and edit history (v2)

[htahaozlu]

Drafts the "Truncate/Edit support" item listed under "RFDs to be Written" in the v2 overview.

Summary

Two methods for in-place modification of a session's conversation timeline:

• session/rewind { sessionId, toMessageId } — truncate history at a message; the next prompt continues from there.
• session/edit_prompt { sessionId, messageId, content } — rewind to a user message, replace its content, re-run from that point.

One capability (agentCapabilities.session.rewind), one new notification (history_truncated) for the destructive event — the symmetric counterpart to the v2 prompt lifecycle's additive user_message. edit_prompt's accept/echo/state_change flow reuses the v2 prompt lifecycle wholesale.

Relation to existing work

• Supersedes #1214, my v1-substrate draft of the same two methods. v1 had no agent-owned message identity and no non-chunk notification, so it could not cleanly express how a truncation is observed by other clients or by session/load replay. v2 settles exactly those questions, so the proposal re-bases onto v2 rather than iterating docs(rfd): Session Rewind #1214 in place.
• Sibling to #1261 (session/inject) — inject is additive ("add this"), rewind is destructive ("undo that"). Shared substrate, non-colliding capabilities/flags, and they compose.
• Rides the v2 prompt lifecycle: agent-owned messageId, user_message echo, state_change.
• Consolidates discussion #239 (checkpoint/restore) and #329 (session/undo/redo).

Out of scope

Filesystem rollback (left to fs/*, session/fork, IDE history, or SCM), conversation branching, and per-edit model/MCP/tool overrides — each noted as future work in the RFD.

---

This PR adds the RFD file only; happy to add the docs/docs.json v2 nav entry (rfds/v2/session-rewind) on request — left out to keep the diff a single clean new file.