/clear and /new don't actually reset the conversation — old history returns on next message

[dnviti]

Problem / Motivation

Using /clear or /new in a chat session appears to reset the conversation — the visible history disappears — but the reset doesn't actually stick. As soon as the next message is sent, the full previous conversation history reappears, and the agent's replies show it still remembers everything from before the "clear." The conversation was never really reset; only the on-screen display was temporarily hidden.

This is misleading: users rely on /clear//new to start a genuinely fresh conversation (e.g. to drop unwanted context, sensitive prior content, or just start over), and right now that guarantee doesn't hold.

Goal

Typing /clear or /new (or triggering an equivalent "new conversation" action) should genuinely start a fresh conversation — with the agent's own memory of prior turns actually discarded, not just hidden from view — and that fresh state should persist across sending new messages and reconnecting/refreshing the page.

Scope

• Make /clear and /new result in an actual fresh conversation, not just a UI-level hide of prior messages.
• Ensure the fresh state is durable: sending a new message afterward must not bring back the old history or have the agent respond as if it remembers the pre-clear conversation.
• Ensure this also holds after a page reload / reconnect (a rejoin shouldn't resurrect the cleared history).
• Give the user a clear, reliable way to start a new conversation (whether via typed command or a UI control) with consistent behavior between the two.

Non-goals

• Preserving or archiving the old conversation for later retrieval as part of this fix (that could be a separate feature).
• Changing how conversations are named, listed, or organized.

Acceptance Criteria

• After running /clear or /new, the next message sent does not surface any prior conversation history in the UI.
• After running /clear or /new, the agent's response does not reflect memory of the conversation that happened before the clear.
• Reloading the page or reconnecting after a clear does not bring back the pre-clear history.
• The behavior is consistent regardless of whether the reset is triggered by typing a command or by any equivalent UI action.

Open Questions

• Should /new remain a supported shortcut distinct from /clear, or should it be treated identically (e.g. both trigger the same "start fresh" action)?

[dnviti]

Landed in #47, on the 5.1.2 release branch.

/clear and /new are no longer forwarded to the running agent — which is why the old context came back on the next message, since the process that remembered everything simply received "/clear" as one more thing to read. They now stop that process and start a fresh one with no resume id, which is what they had always appeared to do.