The usage of state for CSRF mitigation on the redirection endpoint implies that within the state value there’s a unique and non guessable value associated with each authentication request about to be initiated. It’s that unique and non guessable value that allows you to prevent the attack by confirming if the value coming from the response matches the one you expect (the one you generated when initiating the request).
Besides that usage, the state parameter can also be used to encode application state that will round-trip to the client application after the transaction completes; this is sometimes useful so that the application can put the user where they were before the authentication process happened.
In essence, you send a random value when starting an authentication request and validate the received value when processing the response (this implies you store something on the client application side, in session or other medium, that allows you to perform the validation). If you receive a response with a state that does not match you were likely been target of an attack because this is either a response for an unsolicited request or someone trying to forge the real response.
Technically, the fact that this is within a PWA by itself does not impact this flow besides possibly the place where you keep the data that allows to validate the response. For example, assuming the PWA is leveraging a SPA framework then it could store this in local storage while a traditional web application framework would store it in server-side session.