A /clear while the session is open makes the wake path resume the wrong conversation

[snazzybean]

Claudux version

00513f3 (main)

How did you install it?

git clone + npm install (found via code review, not filed from a live install)

OS, Node, tmux, ttyd

N/A. This is a logic bug found by reading the code, not a runtime reproduction on a specific environment.

What happened?

currentSessionId is only ever assigned inside openSession, so after a /clear it still holds the name of the original ("carrier") session. When the app wakes and calls healOpenSessionOnReturn, it posts a resume for that carrier id instead of the session that exists after the /clear.

If the carrier is already dead, the resume route restarts claude --resume <carrier>, which brings back the conversation from before the /clear, and shows a toast claiming a successful recovery for a conversation that isn't the current one.

It gets worse from there: recordClaudeSwitch returns false whenever the ids match, so meta[newId].tmuxSession never gets cleared. The new row stays pinned to the carrier, and the conversation that exists after the /clear becomes unreachable through the interface.

restoreLastSession already made the same identity choice on a plain reload, so this isn't new behavior on its own, just one the wake path now triggers far more often.

Steps to reproduce

1. Open a session, then run /clear inside it.
2. Send the app to the background and bring it back (or otherwise trigger healOpenSessionOnReturn) before touching the session again.
3. The wake path resumes the pre-/clear conversation and reports it as a successful recovery, while the actual post-/clear conversation stays pinned to the carrier row and is unreachable from the UI.

Setup around it

Untested starting point: posting openSessionId(project.sessions) instead of currentSessionId may collapse this into the already-correct case, since for a live /cleared session that resolves to the new row, whose resume already returns the carrier URL unchanged.