fix: reject unauthorized token scope

[LeonRuggiero]

Summary

• treat an STS 403 as a scoped authorization failure instead of silently retrying without account or project scope
• resolve a project-only URL independently instead of combining it with a persisted account
• preserve existing account-only URL and complete localStorage restoration behavior
• invalidate only the rejected persisted selection: remove a rejected project while preserving its account, or remove a rejected account-only selection
• clear the failed in-memory token and matching URL scope so a later user-initiated attempt can recover
• preserve unrelated persisted selections and Firebase hash routes
• surface the authorization failure through the existing sign-in error UI without an automatic retry

Why

Account and project values can come from URL parameters or persisted browser selection. Combining a project supplied by the URL with an account supplied only by localStorage can create an invalid cross-account scope. Project-only URLs now remain project-only, allowing STS to resolve the authorized owning account without inheriting unrelated browser state.

When STS rejects an inconsistent or inaccessible scope, token acquisition remains strict: the rejected request is attempted once and remains visible to the user. The shared session package removes only the rejected browser state so a reload or other explicit retry can recover without clearing all site data or silently entering a personal/default organization.

For a rejected account/project pair, the account is retained and only the project is removed. For a rejected account-only request, the account and its associated project entry are removed.

Test Plan

• pnpm --filter @vertesia/ui test -- src/session/auth/composable.test.ts (39 files, 447 tests)
• pnpm --filter @vertesia/ui lint
• pnpm --filter @vertesia/ui typecheck:test
• pnpm --filter @vertesia/ui build
• dependent @dglabs/composable-ui build (14 tasks)