docs(RFD): add proposal for forking at a specific message

[SteffenDE]

Based on #233 and #536.

The fork RFD already mentioned forking at a specific message. Since we now have the message-id RFD, we can extend fork with this capability to allow features like editing messages, regenerating responses, retroactively branching, etc.

[benbrandt]

I think inclusive makes sense here.
Do we want to say something like this only works on agent messages?
Or, should we allow the agent to provide context on a given fork point?
Do we basically take user messages as the only valid fork points?

I think this could also solve the "edit previous message" case, but maybe then we want a way to say "don't create a new session, just truncate" which only some agents might support (codex would for example) just thinking about the edit use case that you may not always want to fully fork, but maybe we don't have to solve that right now

[SteffenDE]

Do we basically take user messages as the only valid fork points?

I think we can let the agent respond with an error if it cannot fork from a specific message, but assume that by default any message id can be used as fork point.

The edit previous message is our main use case for Tidewave. I think it should still be a full fork. If clients want a "rewind current session" or similar, that should rather be a different method in my opinion, e.g. session/rewind with message id. If the concern is that each edit creates a new chat (listed in the session list), I guess we have to live with that. Maybe agents support deleting sessions at some point, so we could simulate a session/rewind with a fork at id, then deleting the old session.

[benbrandt]

I think we could go with any message, but I also wonder if the agent should indicate a given message is a forkable point? So if you see some property on the message, you know it can fork from there and the client can indicate as such?

[SteffenDE]

I'm wondering if we should have this as a field on the capability, like session: { fork: { atMessageId: { user: true, agent: false, thought: false } } }. But that might not be granular enough depending on the agent.

If it's on the message, the question would be where to put it. The messageId is on the update, so each agent_chunk would need to include not only the messageId, but also canBeForked: boolean (or similar). But then, would it be valid if an agent changes the boolean in a following update? Or should it be a separate session update notification { "sessionUpdate": "message_update", "forkable": true }. Should it be assumed true by default and the agent may send an update to mark it as non-forkable? The other way round? Lots of options.