🤖 fix: soften delayed-start retry banner (#2839)

## Summary

Avoid showing the RetryBarrier's "Stream interrupted" copy while the
first response is still waiting for stream-start.

## Background

In SSH workspaces with long init hooks, the first send can stay in
pre-stream startup for a while before the backend emits `stream-start`.
During that window the frontend still mounted `RetryBarrier`, which made
the warning copy misleading even though the response would eventually
begin.

## Implementation

- detect the delayed-start case when the last actionable row is still
the trailing user message and the workspace remains in
`isStreamStarting`
- render "Response startup is taking longer than expected" for that
state instead of claiming the stream was interrupted
- add a RetryBarrier regression test that covers the delayed-start copy
path

## Validation

- `make static-check`

## Risks

Low. This only changes RetryBarrier copy for the pre-stream startup
state; retry behavior and the actual interruption paths are unchanged.

---

_Generated with `mux` • Model: `openai:gpt-5.4` • Thinking: `xhigh` •
Cost: `$2.42`_

<!-- mux-attribution: model=openai:gpt-5.4 thinking=xhigh costs=2.42 -->

Author: ammar-agent

src/browser/features/Messages/ChatBarrier/RetryBarrier.test.tsx

@@ -136,6 +136,26 @@ describe("RetryBarrier", () => {
     globalThis.document = undefined as unknown as Document;
   });
 
+  test("uses delayed-start copy while the first response is still starting", () => {
+    currentWorkspaceState = createWorkspaceState({
+      isStreamStarting: true,
+      messages: [
+        {
+          type: "user",
+          id: "user-1",
+          historyId: "user-1",
+          content: "Hello",
+          historySequence: 1,
+        },
+      ],
+    });
+
+    const view = render(<RetryBarrier workspaceId="ws-1" />);
+
+    expect(view.getByText("Response startup is taking longer than expected")).toBeTruthy();
+    expect(view.queryByText("Stream interrupted")).toBeNull();
+  });
+
   test("shows error details when manual resume fails before stream events", async () => {
     resumeStreamResult = {
       success: false,

src/browser/features/Messages/ChatBarrier/RetryBarrier.tsx

@@ -242,11 +242,23 @@ export const RetryBarrier: React.FC<RetryBarrierProps> = (props) => {
   const lastMessage = getLastNonDecorativeMessage(workspaceState.messages);
   const lastStreamError = lastMessage?.type === "stream-error" ? lastMessage : null;
   const interruptionReason = lastStreamError?.errorType === "rate_limit" ? "Rate limited" : null;
+  const isWaitingForInitialResponse =
+    lastMessage?.type === "user" && workspaceState.isStreamStarting;
 
   let statusIcon: React.ReactNode = (
     <AlertTriangle aria-hidden="true" className="text-warning h-4 w-4 shrink-0" />
   );
-  let statusText: React.ReactNode = <>{interruptionReason ?? "Stream interrupted"}</>;
+  let statusText: React.ReactNode = (
+    <>
+      {interruptionReason ??
+        // A trailing user message means the backend has not emitted stream-start yet.
+        // Long init hooks (for example over SSH) can legitimately keep us here, so avoid
+        // claiming the stream was interrupted until we have evidence that it actually was.
+        (isWaitingForInitialResponse
+          ? "Response startup is taking longer than expected"
+          : "Stream interrupted")}
+    </>
+  );
   let actionButton: React.ReactNode = (
     <button
       className="bg-warning font-primary text-background cursor-pointer rounded border-none px-4 py-2 text-xs font-semibold whitespace-nowrap transition-all duration-200 hover:-translate-y-px hover:brightness-120 active:translate-y-0 disabled:cursor-not-allowed disabled:opacity-50"