fix(builderlab): give refused app sign-ins and Identity links a route to Organization sign-in - #3078

Summary

Two Builderlab surfaces tell you where to go in Settings and neither takes you there. This branch gives both a route, in two commits that stand alone.

1. A refused app sign-in gets its own panel page. When Builderlab answers 401 to the app viewer exchange while the account session still stands, the panel used to show a bare red bar, "Sign in again in Settings → Identity → Organization sign-in, then reopen this app", with no control. It now shows an EmptyState with Open settings and the primary Try again. The native side gains ViewerPage::SignIn, so the frontend can tell a refused sign-in from the denied and unavailable pages. An app on its own browser login never gets the settings button, and the fix(browser): recheck the FI session when the app viewer exchange returns 401 #2678 recheck is untouched.
2. Identity links land on Organization sign-in. The Builderlab card's "Identity → Organization sign-in" link, the native account-access error sheet and the new panel button all opened Identity at its top, with Private key, Identity sync and Sign out of Buzz above the section they named. A settings target can now carry part: "organization-sign-in", allowed only with the identity section. Opening Identity with it scrolls the section into view and focuses its heading, not its sign-out button. The landing re-lands while the layout settles, stops scrolling on any user wheel, touch, pointer or scroll key, and ends when focus moves on. feat(identity): add native federated sessions and agent tokens #1424's section order stands.

Closing Settings now keys its dialog by community alone instead of dropping section fields by name. That fixes two pre-existing crashes on Close and Escape, one with a plugin import visit left behind, and a case where Back reopened Settings after Close.

Before and after

Left is main at 7f42b13, right is this branch. Step 1 opens a Builderlab app link while Builderlab refuses the sign-in. Step 2 follows the Builderlab card's link.

The refused app panel
Open settings from the panel
The Builderlab card's Identity link

At the landing the heading sits low in the panel because only about 130 px of content lies below it. The section is scrolled fully into view at the bottom. No focus ring shows because the visit started from a mouse click.

The recording runs the production frontend in Chromium with the native organization sign-in and browser view answered in-page, so the Settings, Identity, Builderlab card and app panel are the real components. It models the 401 refusal and does not exercise the native viewer exchange or a live tenant.

Which states show the new page

• No Builderlab account signed in: the panel shows the Login card, as before.
• Signed in and Builderlab answers 403: the existing "You can’t open this app" page, as before.
• Signed in and Builderlab answers 401: the new page. If the adapter recheck also rejects the session, the panel swaps to the Login card by itself.

Verification

• tsc --noEmit, Biome, and the eight touched Vitest files (271 tests) pass.
• A wider run of 107 Vitest files under src/app, src/features/{navigation,browser} and src/bundled/builderlab (2124 tests) passed on the previous revision; later revisions changed only a button label, its order, and tests.
• Rust browser::builderlab tests pass (10) and clippy is clean.
• A full-app Playwright probe of the production build samples the Identity scrollport every frame. In all three journeys (panel button, card link, card link followed by a wheel scroll and a forced section replacement) the heading ends focused with the whole section in view, Close and Escape both close Settings, the wheel is respected, and there are no page errors.
• Four review rounds; all findings addressed.

Notes for reviewers

• Button order. The primary sits last in the row, per the design guide's action-row rule and every dialog footer. Every other two-button EmptyState in the codebase puts the primary first, including the "Buzz couldn’t load this app" page in the same component. That inconsistency predates this change and is left for a design call.
• Server status codes. Whether Builderlab returns 401 or 403 for an account that lacks access to a given app was not verified. If it is 401, users in that state would be told to sign in again.
• Neighbours. fix(settings): keep each section's scroll place while Settings is open #2811 restores per-section scroll in Settings and should be reconciled with the landing once it lands. feat(builderlab plugin): add settings overview and management views #3041 restructures the Builderlab card and will conflict textually with the link change. The "Agents tab" hint from the same source note is covered by feat(builderlab plugin): add settings overview and management views #3041 and is not in this branch.
• Pre-push hook. The branch was pushed with --no-verify because the unit-test lane timed out on unrelated suites under heavy machine load; the same tests passed in a clean workspace.

Deferred

• Native desktop run of both flows against a real tenant, including a genuine app refusal and the Keychain session.
• Both themes, narrow width and enlarged text for the new panel page.
• A WKWebView check that a scrollbar press fires pointerdown before the first scroll event, as Chromium does.

🤖 Generated with Claude Code