Despite the session cookie being SameSite=Strict, we can still CSRF a request to set the memo to contain an XSS payload, and the corresponding session cookie will be set (as part of a response to a top-level navigation). We can also stop the cookie from being overridden by cancelling the redirect to / (via hitting the redirect limit). The remaining part of the challenge is to actually send this cookie with a navigation request.
When the headless bot navigates to a page with page.goto(), the initiator is null, which is treated as same-site with the request URL. Adjacently, when a request is made in Chromium, if the initiator site and target site agree according to this prior check, then SameSite=Strict cookies will be sent regardless of whether the chain of redirects to the target site included a cross-site redirect or not, by default. (See this. See discussions here.)
For our purposes, this means that we can send the bot to our page, perform CSRF, then navigate away and then history.back() (making sure to invalidate bfcache and disk cache); this will trigger another navigation request to our initial URL with the initiator being null (the initiator is stored with the history entry) to which we can simply respond with a redirect to the challenge page (and the resulting request will include SameSite=Strict cookies).
(A similar case used to exist for chrome-extension:// URIs, which allowed you to bypass web-accessible resource checks if the initiator was null, but this is no longer possible since you can't HTTP redirect to chrome-extension:// URIs anymore.)