No, issuer-client unlinkability is a feature of the design. The token is finalized by the client using private inputs so Kagi never actually sees the redeemable token (until it's redeemed).
Using the example doc you’re citing from kagi.com - though not the RFC, I don’t have the time to dive into that one at the second, I see that a session token plus some other stuff is passed in and a token comes out.
Where does it show that on the Kagi backend they couldn’t, theoretically, save the session key before performing the token response?
Sure, they probably do. Doesn't matter because neither the session key nor the token response can be linked to the tokens.
If you're not going to make an effort to understand how it works, don't make assertions about how it works. Ask your favorite LLM about the RFC if you have any further questions.
https://blog.kagi.com/kagi-privacy-pass#token-generation:~:t....
https://www.rfc-editor.org/rfc/rfc9576.html