fix(dash0): send a session that lands on an unusable org to one it can use

[fclairamb]

Spec 2026-09-08-01-redirect-to-an-accessible-org.

The bug

On production v0.26.0, entering the live demo from solidping.io/dash0/orgs/default/login left the visitor in /orgs/default — an org the demo user is not a member of. Every request 403s, the layout shows "Permission Denied", and that card's only button links back to the same org. A dead end with no way into the demo.

Two paths produced it. The "Try the live demo" button raced its own sign-in: login() flips isAuthenticated, the already-authenticated effect fires with the URL's org and replaces over the in-flight navigation to the demo. Spec 2026-09-07-02 silenced that effect for the ?demo flag and left the button path with it. Separately, a returning visitor still holding a demo session hit the same wall with no race at all, just by opening a plain login link.

The existing E2E caught neither: it waited for /orgs/[^/]+/, which the login page's own URL already matches, then asserted a banner that renders on every org page.

The general problem underneath

Any session can land on an org URL it cannot use — a bookmark to an org you were removed from, a colleague's link, a slug from an old email. The layout already re-mints the token when the URL org is one of yours; when it is not, the comment said "non-members fall through to the normal 403 handling". Nothing ever sent you somewhere usable, even though the client already holds the full list.

What changed

• lib/accessible-org.ts — one pure, unit-tested helper both call sites share, so the two redirects cannot disagree: super admin → URL org; URL org if you're a member; else the session's org (which is "last accessed", since every login and switch re-mints the token); else organizations[0]; else /no-org. This mirrors what the backend already does at login time in resolveDefaultOrg.
• Login page resolves through the helper instead of the raw URL org, which fixes both demo paths.
• Org layout sends a non-member to the picked org's root (sub-paths don't survive an org change) with a toast, loop-guarded per org and skipped while a switch is in flight.

The audit caught a regression this introduced

The independent audit found that completeLoginAfter2FA was the one login path returning no organization list, so applyLoginResponse fell back to /auth/me — and that await ends React's auto-batch, committing a render with isAuthenticated, !isLoading and an empty list. The new effect read that as "belongs to no org" and bounced TOTP users through /no-org. Fixed at both layers: the 2FA response now carries the list like every other login shape, and isLoading is held up across the fallback so no render exposes a half-built session.

The existing 2FA E2E could not have caught it — it waits for a URL merely not containing /login, which /no-org satisfies. The new test records pushState/replaceState instead, because a final-URL assertion cannot see a redirect that a later one corrects.

Verification

• The tightened button test failed 5 runs out of 5 pre-fix — deterministic, not timing-lucky — and passes 3/3 after.
• A negative control for the layout guard: neutered, the two non-member tests fail and the positive controls still pass.
• The new 2FA test confirmed failing pre-fix.
• test@test.com turned out to be a superadmin, so the spec's suggested "sign in as the test user" would have asserted nothing; the general E2E provisions a real ordinary member and keeps the superadmin as the "URL org kept" variant.
• Backend build/lint/test green; dash0 lint at its documented 42-error baseline with no new errors in touched files; test:unit 1505 passing; 27/27 Playwright across the three affected specs.

🤖 Generated with Claude Code