fix: do not let an in-flight open blank a newer prompt, or promise a bridge that is off

Two findings from review of this branch.

Awaiting the open instead of dismissing up front bought a window: on Linux
it is at least OPENER_GRACE, doubled when xdg-open fails and gio is tried.
If the container relays a second URL inside that window, the first open's
resolution blanked the second prompt -- losing a link that exists only in
the container's transcript, which is the failure "dismiss on success only"
was made to prevent. The slot already carried a `seq` for exactly this
reason; dismissal is now conditional on it.

`urlPromptRef` is written eagerly by the two functions that change the slot
rather than synced by an effect. That is load-bearing: an effect-synced
mirror lags state by a commit, and a promise microtask can resolve between
`setUrlPrompt` and React flushing passive effects -- so it answers "did a
newer prompt land?" wrong in precisely the window the guard exists for.
Dropping the functional updater also fixes `promptSeqRef.current += 1`
being mutated inside a state updater React is free to invoke twice.

The guard is a sibling function rather than an optional argument on
`dismissUrlPrompt`, because that function is passed by reference as
UrlToast's `onDismiss` and React would hand it a MouseEvent as its first
argument -- the seq check would fail and the close button would silently
stop working, with the types still assignable.

Separately, the sign-in hint was binary on which button leads, but "host
leads" covers both a live bridge and a fallback where nothing is set up to
catch the callback at all. In the second case the toast promised the bridge
would carry it and the login hung to its timeout. The target is now
three-state, the hint tells the truth in the fallback case and names the
control that fixes it, and the hook starts at `host-fallback` rather than
assuming a bridge it has not confirmed.

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

app/src/components/terminal/UrlToast.test.tsx

@@ -199,15 +199,14 @@ describe("UrlToast", () => {
       );
     });
 
-    it("leads with the host when the caller says so, without hiding the other", () => {
-      // A live auth bridge, or a container with no browser installed. The pair
-      // is unchanged; only the order and which one is filled.
+    it("leads with the host, and promises the bridge, when the bridge is live", () => {
+      // The pair is unchanged; only the order and which one is filled.
       render(
         <UrlToast
           url={SIGN_IN}
           onOpen={noop}
           onOpenInContainer={noop}
-          signInDefault="host"
+          signInDefault="host-bridged"
           onDismiss={noop}
         />,
       );
@@ -215,15 +214,46 @@ describe("UrlToast", () => {
       expect(
         document.querySelector(URL_TOAST_PRIMARY_SELECTOR),
       ).toHaveTextContent("Open");
-      // Still recognised as a sign-in, so the explanation stays.
+      // Still recognised as a sign-in, so the explanation stays — and here the
+      // explanation is true, which is the only state in which it may be given.
       expect(screen.getByTestId("url-toast-signin-hint")).toHaveTextContent(
-        /auth bridge/i,
+        /the auth bridge is what carries the callback/i,
       );
     });
 
-    it("defaults to the host when the caller passes nothing", () => {
-      // The safe fallback: the answer more likely to work, and the one that
-      // reports its own failure.
+    it("says the callback has nothing carrying it when the host is the last resort", () => {
+      // `host-fallback`: bridge off or unknown *and* no browser in the
+      // container. The old two-state hint said the auth bridge would carry the
+      // callback here too, which is a false promise — the user opens the link
+      // in their own browser and `claude login` hangs to its timeout with
+      // nothing on screen explaining why.
+      render(
+        <UrlToast
+          url={SIGN_IN}
+          onOpen={noop}
+          onOpenInContainer={noop}
+          signInDefault="host-fallback"
+          onDismiss={noop}
+        />,
+      );
+      // Which button leads does not change — only what the hint claims.
+      expect(actions()).toEqual(["Open", "In container"]);
+      expect(
+        document.querySelector(URL_TOAST_PRIMARY_SELECTOR),
+      ).toHaveTextContent("Open");
+      const hint = screen.getByTestId("url-toast-signin-hint");
+      expect(hint).toHaveTextContent(/nothing is set up to reach it/i);
+      // And it points at the two things that would fix it, since a warning
+      // with no next step is only a nicer way to fail.
+      expect(hint).toHaveTextContent(/Auth bridge/);
+      expect(hint).toHaveTextContent(/install browser support/i);
+      expect(hint).not.toHaveTextContent(/the auth bridge is what carries the callback/i);
+    });
+
+    it("defaults to the least-bad reading when the caller passes nothing", () => {
+      // A caller that says nothing has not told us a bridge is live, so the
+      // hint must not invent one. The host still leads: it is the answer more
+      // likely to work, and the one that reports its own failure.
       render(
         <UrlToast
           url={SIGN_IN}
@@ -233,6 +263,9 @@ describe("UrlToast", () => {
         />,
       );
       expect(actions()).toEqual(["Open", "In container"]);
+      expect(screen.getByTestId("url-toast-signin-hint")).toHaveTextContent(
+        /nothing is set up to reach it/i,
+      );
     });
 
     it("keeps the host browser available as a fallback", () => {