Feature Request: Integrate Chat Component within Student Space

[Dakir-Ai]

Is your feature request related to a problem? Please describe.

Currently, the chat component exists outside of the student space. Students have to navigate away from the student interface to access the chat functionality, which disrupts the user experience and creates inconsistency in the UI.

Describe the solution you'd like

Integrate the chat component directly within the student space, making it accessible through the student sidebar and navbar. All student features should maintain a consistent structure with the same sidebar and navbar layout.

Describe alternatives you've considered

1. Keeping the chat as a separate component but adding direct links from the student space.
2. Creating a simplified chat version specifically for the student space.

Additional context

The current implementation already has a placeholder for chat in src/routes/student/chat/+page.svelte but it's not fully integrated with the main Chat component. The main chat functionality is implemented in src/lib/components/chat/Chat.svelte and needs to be properly connected to work within the student layout which has its own sidebar and navbar structure.

We need to update the student chat page to properly use the main Chat component while ensuring it works within the student layout context.

[musaabhasan]

I would treat this as an integration boundary problem rather than creating a second student-chat implementation.

A clean approach would be:

1. Keep src/lib/components/chat/Chat.svelte as the single chat surface, but make its dependencies explicit through props or context: student id, active course/class context, conversation scope, initial thread id, and any feature flags.
2. Let src/routes/student/chat/+page.svelte become a thin composition layer inside the student layout. It should import the shared Chat component, pass the student-space context, and preserve the same sidebar/navbar shell instead of redirecting students to a separate chat area.
3. Separate navigation availability from chat authorization. Showing a sidebar link is a UX decision; loading a conversation should still verify that the student belongs to the requested class/course and can access the selected thread.
4. Make conversation scope visible in the UI. For example, distinguish personal tutoring chat, course-specific help, and assignment-specific help so students do not accidentally ask in the wrong context.
5. Add regression checks around layout and access: direct visit to /student/chat, sidebar navigation into chat, refresh with an existing thread, unauthenticated access, and a student trying to open a chat outside their enrolled course.

For the first implementation, I would avoid a simplified duplicate chat. It will drift quickly. A shared component with a student-space adapter keeps the experience consistent while still allowing the student page to control layout, permissions, and course context.