Fix critical socket authorization issues

[coder13]

Summary

• prevent the Express session signing secret from being sent as the Engine.IO cookie name
• authorize room deletion against the persisted target room owner or admin
• replace the removed Socket.IO 3 remoteLeave calls with Socket.IO 4 socketsLeave
• persist kick and ban state before ejecting sockets, then reject every later room event when inRoom is false or the user is banned
• contain synchronous throws and rejected promises from all room event handlers, with safe optional acknowledgements for join/create/delete events
• reject anonymous joins to identity-required rooms without dereferencing a missing user

Root Cause

The Socket.IO configuration reused AUTH_SECRET as an Engine.IO cookie name. Room deletion checked authority on the caller's current room while deleting an arbitrary client-supplied room ID. The Socket.IO 4 adapter no longer implements remoteLeave.

Replacing remoteLeave alone was insufficient: it removed adapter room membership but left socket.roomId intact, so a hostile client could ignore the kick/ban notification and keep sending mutations. Async Socket.IO listeners were also registered directly, allowing malformed payloads or missing acknowledgement callbacks to escape as unhandled rejections under Node 22.

Security Behavior

Room event middleware now reloads persisted room state and requires authenticated users to remain present and unbanned. Kick and ban operations save that state before notifying and removing sockets from adapter rooms. A shared handler wrapper catches synchronous and asynchronous failures and returns a generic error without exposing internal details.

Validation

• yarn workspace letscube-server lint
• yarn workspace letscube-server test --runInBand — 4 suites, 10 tests
• repository pre-commit gate: yarn lint && yarn test — client and server checks passed