Say what "open in container" is doing, and land on the pane doing it

Opening a page is a container probe, a browser launch, a page load and
often a viewer start — several seconds during which the only feedback
was the click itself. Worse from a terminal, where the result appears in
a pane the user is not looking at.

So: the backend emits progress on the existing `container-progress`
channel at each step, the Browser tab renders that line whenever it is
set — the progress belongs to the project, not to whoever pressed the
button, which is what lets a terminal-initiated open report anywhere at
all — and the terminal's "In container" now selects the project's
Browser tab before starting, so the line has somewhere to appear.

Selecting a sub-tab from outside needed a route: `ProjectHome` keeps it
in local state, so `openProjectHomeTab` parks a request in the store and
the pane consumes it once. Consumed once, so it cannot fight the user's
own clicking afterwards.

Preview releases now prune themselves to the newest KEEP_PREVIEWS (2),
in a job that runs only if all three platforms published — a
half-finished run must not evict a good older build. The cleanup
workflow's manual sweep stays as the backstop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

app/src/components/terminal/TerminalView.tsx

@@ -554,6 +554,9 @@ export default function TerminalView({ sessionId, active }: Props) {
       return;
     }
     if (!projectId) return;
+    // Land on the pane that will show it, before the work starts: opening takes
+    // several seconds, and the progress line lives there.
+    useAppState.getState().openProjectHomeTab(projectId, "browser");
     // A sign-in page is the one case where the *window* size matters least and
     // the layout matters most, so it gets the ordinary desktop viewport.
     // `true`: from a terminal there is no Browser pane on screen, so the page