Redirect or dialog: which expiry UX fits Vaadin's least-privilege view access model?

I'm designing the security layer for a Vaadin Flow application (Vaadin 24 with Spring Security 6) and want least-privilege access enforced server-side. My plan is to deny by default and annotate route targets with @RolesAllowed and @AnonymousAllowed, letting ViewAccessChecker block navigation before the view renders, plus @PreAuthorize on the services behind my binders.

The part I can't settle is what should happen when credentials expire mid-session. As I understand it, an expired HTTP session only surfaces on the next navigation or UIDL request, the Vaadin heartbeat doesn't extend the underlying security session, and with push enabled the WebSocket channel may outlive the session unless I align the websocket authorization rules myself. Vaadin appears to offer hooks such as a custom SessionExpiredHandler, but no prescribed UX.

The two options I'm weighing: silently redirect to the login view (simple, but the user loses navigation state and any unsent input), or intercept expiry and show a session-expired dialog that preserves context before re-authentication.

Does ViewAccessChecker treat an expired session the same as an unauthenticated user on the next navigation, or do I need separate handling for the two cases? With push enabled, which component is actually responsible for closing or re-authorizing the channel after expiry? And is there a documented way to preserve the target route through re-login without weakening the deny-by-default model?