feat(browser): show a refused Builderlab app as a page in the panel - #2680

…retries

The "Buzz couldn't load this app" page now stays mounted during a retry
(from #2680's fix), so its focused Try again keeps focus. Put that button
in its loading state too, so the retry shows as pending and repeat
presses are ignored, as on the refused-app page.

Co-authored-by: Dylan G <69953f73c9f5149d56f2155107338a5435823b938a6c430c63e779f9a8a446f9@remote-agent-pilot.communities.buzz.xyz>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Nathan Thillairajah <[email protected]>

…urns 401 (#2678)

When Buzz opens a Builderlab app in its side panel, it exchanges your
organization sign-in for a viewer cookie. If that exchange comes back
401, the panel asks you to sign in again, but Settings → Identity still
says you're signed in. The two disagree until something else notices.

Now a 401 from the exchange triggers one background check with the
sign-in adapter, using the existing `FederatedIdentity::recheck` that
agent decisions and community API calls already use. If the adapter says
the session ended, it moves to "reauthentication required" and Settings
follows. If the session is still good, nothing changes, so a stray 401
can't sign anyone out. Other failures (403, 5xx, network) and dev broker
sessions don't trigger the check, and the panel's error text is
unchanged.

## Testing

Unit tests cover both outcomes of the 401 check and the cases that skip
it.

Manually tested on macOS by nthillairajah in a local dev build that
combined this PR with #2680 and #2681. The build also had a local-only
switch, not part of any PR, that fakes the exchange's answer. With a
faked 401, the panel showed the sign-in-again message and Settings still
showed the organization sign-in as active. A normal app link loaded
fine. We couldn't fake Builderlab actually revoking a session, so the
"session really ended" path is only covered by the unit tests.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Nathan Thillairajah <[email protected]>
Co-authored-by: Dylan G <69953f73c9f5149d56f2155107338a5435823b938a6c430c63e779f9a8a446f9@remote-agent-pilot.communities.buzz.xyz>
Co-authored-by: Claude Opus 5.5 <[email protected]>

…able-page

* origin/main:
  feat(browser): show a refused Builderlab app as a page in the panel (#2680)
  fix(profiles): cache profiles on disk and keep dm partners through eviction (#2178)
  feat(profiles): let each reader show verified people by username or full name (#2356)
  fix(media): show transparent avatars without a black background (#2477)
  fix(channels): keep the reader's place when Back returns to a link-opened channel (#2500)
  BUZZ-518: Explain required community sign-in (#2710)
  feat(desktop): serve credentials to agents and your CLI, with pairing (#2260)
  test(solo): wait for search and access before Share focus reveal (#2573)
  fix(relay): answer bytes a failed spool wrote; deflake the memory read (#1970)
  ci(release): publish a signed Intel macOS DMG (#1825)

Signed-off-by: Nathan Thillairajah <[email protected]>

# Conflicts:
#	docs/browser.md
#	src-tauri/src/browser/builderlab.rs
#	src/features/browser/BrowserHostView.test.tsx
#	src/features/browser/BrowserHostView.tsx
#	src/features/browser/platform.test.ts

…n and Open in browser (#2681)

When Buzz can't reach Builderlab to open an app in the side panel (a
network failure, a 5xx, or a reply it can't read), the panel shows
"Builderlab sign-in request failed" in a red bar above an empty page,
with no way to retry.

Now those failures show a page: a cloud icon, **Buzz couldn’t load this
app**, and two buttons. **Try again** retries. **Open in browser** opens
the app in your default browser, where the app's own login takes over.
If the browser can't be opened, the page says so. 401, 403 and 404
behave as before, and bad URLs or credentials still use the red bar.

## Testing

Rust and Vitest tests cover which failures get the page, both buttons,
and the case where the browser can't open.

Manually tested on macOS by nthillairajah in a local dev build that
combined this PR with #2678 and #2680. The build also had a local-only
switch, not part of any PR, that fakes the exchange's answer. A faked
network failure and a faked 503 both showed the page with no red bar.
Open in browser opened the app in the default browser, and Try again
failed the same way, as expected while the fake was still on. A normal
app link loaded fine. We didn't test with a real network outage.

After that test, a review on #2680 found that Try again lost keyboard
focus while retrying. This page gets the same fix (keep the page up
during the retry, with the button in its loading state). That's covered
by a unit test and was rechecked by nthillairajah in a local build
before main was merged in (the merge changed no code in this PR):
tabbing to Try again and pressing Enter repeatedly keeps focus on it. If
a retry ends in some other error instead, focus moves to the error
message. A unit test covers that part, but it hasn't been checked in the
app.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: Nathan Thillairajah <[email protected]>
Co-authored-by: Dylan G <69953f73c9f5149d56f2155107338a5435823b938a6c430c63e779f9a8a446f9@remote-agent-pilot.communities.buzz.xyz>
Co-authored-by: Claude Opus 5.5 <[email protected]>