feat(backend): introduce vitals status update

name: Feature Request
about: Suggest a new feature or enhancement for the Corpus Collector Backend.
title: "[Feature]: feat(backend): introduce vitals status and vitals queue workflow"
labels: "feature"

🚀 Feature Request

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

Currently, the patient workflow is strictly doctor-centric. When a patient is assigned to a doctor or specialization, they are immediately placed into the doctor's "Waiting" queue. This bypasses the mandatory Vitals Check stage. As a result, doctors often see patients in their queue whose vitals have not yet been recorded, leading to workflow inefficiencies and confusion during consultations.

Describe the solution you'd like

Introduce a dedicated Vitals Queue and an intermediate consultation status vitals.

Proposed Workflow:

1. Assignment: When a patient is assigned to a doctor or specialization, they are placed into the queue with status vitals instead of entering the consultation queue directly.
2. Vitals Queue: The Vitals Queue page subscribes to the queue_doctors WebSocket room and filters for patients with status vitals. Volunteers use this view to identify patients waiting for vitals.
3. Vitals Recording: Upon successful vitals recording, the system transitions the patient from vitals → waiting.
4. Doctor Queue: The Doctor's Queue page also subscribes to the queue_doctors WebSocket room but filters for patients with status waiting or in_consultation.

Technical Changes:

• Database: Added vitals to QueueStatusEnum (replacing the proposed vitals_pending).

Service Logic:

• Assignment: create_or_update_queue_record sets the initial status to vitals.
• Queue Retrieval: Updated get_doctor_queue and get_all_active_queue to include patients with status vitals (and consultation_completed).
• This allows a single API endpoint / WebSocket room to serve both the Vitals Queue and the Doctor Queue views, with filtering handled on the frontend.
• Status Transition: Implemented valid state transition: vitals → waiting.

API & WebSocket:

• WebSocket: Updated socketio_queue_manager.py to broadcast patients with vitals and consultation_completed statuses to the queue_doctors and queue_coordinators rooms.
• Endpoints: Reused existing GET /api/v1/queue/doctor/{doctor_id} and GET /api/v1/queue/all endpoints (now returning all statuses) instead of creating a separate /vitals endpoint.

Describe alternatives you've considered

• Separate Endpoints: Originally considered a dedicated /api/v1/queue/vitals endpoint. We opted to unify the queue data into existing endpoints and WebSocket rooms to simplify the backend and reduce the number of open socket connections required on the client.
• Manual Status Update: Rejected in favor of automatic transition upon vitals recording.

Additional context

This change enforces a clear and structured patient flow:
Registration → Assignment → Vitals → Doctor Consultation, ensuring doctors only see consultation-ready patients in their queue.