fix: new-session button + sidebar resume don't actually switch Pi sessions (#52, #55, #57)

[Elompenta]

Summary

Fixes #52 (and the duplicate report in #55): clicking the new-session ("+") button cleared the chat visually but never actually started a new Pi session — the next message kept appending to the old one, and nothing new showed up in the sidebar.

Also fixes #57: selecting a session from the sidebar only ever opened a read-only preview, with no way to actually make Pi switch to it — see the added section below.

Why the previous fix (b71ab87) wasn't enough

That commit added the new-session-btn click handler, but it only resets local browser UI state (cost display, message renderer, sidebar highlight). It never calls the backend at all. There's a separate newSession() function in the same file that does the right thing (calls switchSession(null)) — but nothing ever calls it. It's dead code that looks like the real fix while sitting unused, which is exactly what made this hard to spot in review.

Even fixing just that wouldn't have been enough: switchSession(null) posts to /api/sessions/switch, and that endpoint is a mirror-mode no-op stub ({success: true, mirror: true, note: "Session switching is controlled by the TUI in mirror mode"}) — it never touches the actual Pi session either way.

What's actually going on, and the fix

Starting a new session from an extension isn't something sendUserMessage("/new", …) can do — /new is a built-in TUI command, and expandPromptTemplates on sendUserMessage only dispatches extension-registered commands and prompt templates, not core ones (confirmed by reading pi-coding-agent's source: agent-session.js's prompt()/_tryExecuteExtensionCommand()). The real API is ctx.newSession() on ExtensionCommandContext, only available inside a registered command's handler.

So this PR:

1. Registers an internal tau-new-session command whose handler calls ctx.newSession(), and has the WS new_session case dispatch it via sendUserMessage("/tau-new-session", { expandPromptTemplates: true }) — the same pattern used elsewhere in the Pi extension ecosystem for triggering extension-owned commands programmatically.
2. Removes the dead newSession() function, replaced by the above.
3. Fixes a pre-existing "pipe mode" filter bug in serveSessionsList()/parseSessionFile(): it hides sessions with userMessageCount <= 1 && lineCount <= 8 to avoid cluttering the list with non-interactive pi -p "..." one-shots — but a genuine fresh interactive session's own bookkeeping entries (model_change ×2, thinking_level_change, the startup-doc welcome message) push it to exactly that same shape with just one exchange. Every brand-new session was hitting this and staying invisible until a second message was sent in it — this is what made the bug look like "works once, then stops" when testing: each new session only ever had one exchange, so all of them tripped the filter. Now the filter is skipped when the file has entries only a real interactive/RPC run produces.
4. Refreshes the sidebar when a turn ends (only for a session not yet listed — see point 3) and on WS reconnect, since a session file is only written to disk once it has its first assistant reply.
5. Blocks repeat clicks on the button while a restart cycle is in flight: every session replacement tears down and restarts the whole mirror server (session_shutdown → session_start), dropping and re-establishing the WS connection; clicking again before that finishes raced the restart.
6. Removes the live-session dot's pulsing animation. Confirmed via devtools that the animation property alone (independent of how often the sidebar re-renders) made the dot flicker distractingly. Static dot (color + glow) still reads as "live".

#57: resuming a session from the sidebar

Same underlying constraint as the new-session fix: switching sessions from an extension needs ctx.switchSession(path) on ExtensionCommandContext, which is only reachable from inside a registered command's handler — there was no path from the sidebar to that at all, so every non-live session was permanently read-only.

Adds a second internal command, tau-switch-session, dispatched the same way as tau-new-session (with the session path as its argument). Selecting a session from the sidebar now sends it (skipped when that session is already the live one, to avoid a pointless restart) alongside loading its history for immediate feedback — no extra step needed, since browsing the sidebar to a session is already the expression of intent to switch to it. The resulting session_shutdown → session_start cycle drops and re-establishes the WS connection exactly like the new-session flow, and the existing connected/mirrorSync handling this PR already added picks up the switch and moves the live indicator there — no separate plumbing needed.

Testing

Reproduced and verified end-to-end against a real running Pi instance + browser (not just unit-level):

• New session: clicked "+" three times in a row, each with a message sent in between, confirming each new session appears in the sidebar immediately after its first reply and stays there without disturbing the live indicator on subsequent turns in the same session.
• Resume: created two sessions, clicked the older one in the sidebar, confirmed the live dot moved to it, the session became writable again, and a new message sent afterward landed in the correct (resumed) session file. Repeated across a fresh page load and a brand-new tab to rule out stale client state.