I'm not sure this is an actual issue:
I don't think it is.
- Scribunto sessions are extremely ephemeral.
Indeed. It's not saved anywhere persistent client-side so it's gone as soon as the person leaves or reloads the page, plus it's thrown away if the user clicks the "Clear" button or changes the textarea in the edit form.
- What would an attacker even gain by messing with someone's scribunto debug session?
The "session" here is just the history of commands previously typed into the console and a copy of the previous value of the content parameter, so they don't have to be repeated for every request. The best an attacker could do would be to screw up the Lua code being run, either to confuse someone or to hope they're going to copy-paste output.
- Each session has a 31 bit (non-cryptographically secure. i.e. generated via mt_rand()) random identifier associated with it. The attacker would have to be able to guess this. Given its only 31 bits, and its not securely generated, this isn't outside the realm of possibility, but it also makes things harder to pull off.
Note the cache key also includes the user's ID. So the attacker would either have to also be able to spoof the user somehow or restrict the attack to people using the console while logged out.
We generally require POSTs and CSRF tokens for actions that actually write the wiki. This doesn't, other than that ephemeral state cache.