fix: validate roomId in WebRTC signaling handlers

[LakshmiSravyaVedantham]

Summary

• Adds Socket.IO with WebRTC signaling server to server.js, including a validateRoom() helper that checks both activeStreams.has(roomId) and socket.rooms.has(roomId) before forwarding messages
• The offer, answer, and ice-candidate handlers now reject signaling attempts for non-existent rooms or sockets that have not joined the room, emitting a descriptive error event back to the caller
• Adds socket.io as a production dependency in package.json

Closes #106

Test plan

• Start server and verify Socket.IO connects on ws://localhost:3000
• Emit offer/answer/ice-candidate with an invalid roomId and confirm an error event is received
• Emit signaling events from a socket that has not joined the room and confirm an error event is received
• Start a stream, join as viewer, and verify signaling messages flow correctly through the validated handlers

[gbowne1]

@LakshmiSravya123

This is great but this wont work without #61 and or #68 for live chat and live stream functionality applied to master branch

Thanks for the attempt

With this change there would be a lot of overlap between this PR and #61 #68.

Am currently not supporting merge of this PR.

It also appears that this PR was generated by Claude AI. While I'm mostly okay with that, I'd rather have actual working code first then use AI to debug the code and its issues rather than generate the entire solution

[shishir-21]

@LakshmiSravya123
@gbowne1
I reviewed the implementation focusing on signaling validation and architectural impact.
The validateRoom() helper is a good addition and improves signaling security by ensuring that:
-The room exists in activeStreams
-The socket has joined the room before forwarding WebRTC messages

However, I noticed a few blocking concerns:
1.) This PR introduces WebRTC signaling logic that overlaps with #61 and #68, which are not merged into master yet. This may cause duplication or architectural conflicts.
2.)The server is started using both app.listen and httpServer.listen, which can cause runtime errors.
3.)The use of the error event for custom error messages may conflict with reserved Socket.IO behavior.
4.)There is no authentication middleware applied to the Socket.IO connection.

I recommend rebasing this PR after #61/#68 are merged

[gbowne1]

I just now merged #61 but #68 still blocked this

I would still recommend not using this. We don't even have tests for this

[shishir-21]

@LakshmiSravya123
@gbowne1

Thanks for the update.

I see that #61 is now merged, but since #68 is still pending and this branch has conflicts in server.js, I recommend resolving the conflicts and rebasing against the latest master first.

Given the architectural overlap and lack of tests, it may be better to revisit this implementation after #68 is merged to avoid duplication and instability.

[gbowne1]

@shishir-21 @glenjaysondmello @Ved178 I've completed the first couple rounds of refactoring this app and just released #117 so this work done in this PR will have to be completed once the refactoring changes have been merged closing this also due to merge conflict's that wouldn't work without significant work to it