Resolution must stay synchronous with the store. Anything awaited
here before resolveAction deadlocks: the awaited request would 310/311/312
itself, coalesce onto the entry still sitting at the head of the queue
(action-dialog-store.ts), and wait for the resolveAction that is waiting
on it. Post-resolution checks belong in the auth flow — see verifyAppAccess
in @enode/core/auth/app-access.
Hosts the redirect-resolution surfaces, driven by the global action-dialog store. Mount once in each app's root layout. When
apiRequesthits a 310/311/312 it opens the matching surface here; resolving/cancelling settles the store promise so the original request resumes (resolved) or fails (cancelled).310/312 are bottom-sheet dialogs; 311 is a full-screen onboarding page. All are kept mounted with a toggled
openso they can animate; each decodes its body defensively, so the brief null body during a close transition is harmless.