Fix websocket panics on session disconnect

[jackmaninov]

Summary

Fixes multiple race conditions and error handling issues in websocket session management that caused panics during unauthenticated visitor access and login redirects.

Problem

When unauthenticated users connect via WebSocket (e.g., during redirect from base URL to login page), several issues can occur:

1. Nil pointer dereference: disconnect() sets conn = nil while read()/write() operations are pending, causing panic when they try to use the connection
2. Read loop spinning: errHandler() returned nil for close errors, causing the read loop to continue instead of exiting. After ~1000 iterations, gorilla/websocket triggers a safety panic
3. Send on closed channel: Write() could attempt to send to s.send channel after disconnect() closed it
4. Noisy error logs: Expected close conditions (1006 abnormal closure, "close sent") were logged as errors

Changes

• Add nil checks in read() and write() after acquiring lock to prevent nil pointer dereference
• Return net.ErrClosed from errHandler() for close errors to exit read/write loops cleanly
• Add atomic.Bool closed flag to session, set before closing channels in disconnect()
• Check closed flag in Write() before attempting channel send
• Handle additional expected close codes (1005, 1006) and "close sent" error in errHandler()

Testing

• Existing websocket tests pass
• Manually verified with unauthenticated visitor access and login redirect flow

Fixes #2223

[jackmaninov]

Not sure if you have an AI generated code policy, but this was done supervised and tested on my production environment.

[Fajfa]

If the code is good and resolves the issue, then it will be accepted. Thanks for contributing.

[github-actions]

Stale pull request message