feat(session): prevent multiple simultaneous sessions on the same device

[Calais1986]

Summary

This Pull Request introduces a mechanism to prevent multiple simultaneous ws-scrcpy sessions on the same device.
The goal is to avoid collisions, race conditions, and unexpected behavior caused by concurrent connections trying to control or stream the same device.

This implementation is compatible with the existing architecture and does not introduce breaking changes.
When a second client attempts to connect to a device that is already locked by an active session, the server now detects the conflict and rejects or defers the new connection.

---

What’s Included

✔ Device-level Session Lock

• A new device-level lock is introduced to track whether a device is currently in use.
• Prevents multiple clients from controlling the same device simultaneously.

✔ Updated WebSocketServer logic

• The session admission workflow now checks if the device is already locked.
• If locked, the connection is refused cleanly with a descriptive error.
• Lock is released when the WebSocket session ends (disconnect, error, or client close).

✔ New Device Lock Utility

A new module (device-lock.ts) manages:

• Acquisition of locks
• Safe release of locks
• Internal state tracking
• Preventing stale/abandoned locks

✔ Cleanup Logic

Ensures locks are always released even in edge cases:

• Unexpected socket close
• Browser tab crashes
• Network errors
• Backend exceptions

---

How It Works

1. When a client requests access to a device:
   • The server checks the lock state for that device.
2. If no lock exists, the device is locked and session proceeds normally.
3. If a lock exists, the request is denied with:

   { "error": "device-in-use", "message": "Another session is active for this device" }

[LWHikarik]

Sometimes end users may need to view device session from several browsers, for example on demos. No need to lock devices without desired intention