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).
https://blog.kagi.com/kagi-privacy-pass#token-generation:~:t....
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?