[RESOURCE APP][FRONTEND][REFACTOR] Replace legacy `/bookings/{id}/process` with `PUT /bookings/{id}`

[saknarajapakshe]

Summary

The frontend currently calls the legacy endpoint PATCH /bookings/{id}/process. Backend now uses a unified endpoint PUT /bookings/{id} (UpdateBookingRequestPayload), and the legacy endpoint will be removed. This issue tracks updating the frontend to use the unified endpoint and payload shape.

Background

• Legacy endpoint: PATCH /bookings/{id}/process (to be removed)
• New endpoint: PUT /bookings/{id} — payload fields: status (required), reason, proposedStartTime, proposedEndTime
• Related backend PR: [RESOURCE APP][BACKEND][FEAT] Implement Action-Based Handler with Separate DTOs for Booking Actions #157
• Related backend issue: [RESOURCE APP][BACKEND][REFACTOR] Implement Booking Lifecycle with Action-Based Single Endpoint #153

Required changes

1. Replace API call:

   • From:

     httpClient.patch(`/bookings/${id}/process`, { status, rejectionReason })

   • To:

     httpClient.put(`/bookings/${id}`, { status, reason: rejectionReason })

   • Or rename the parameter to reason and forward it directly: { status, reason }

2. Update bookingApi.processBooking signature to accept and forward reason, proposedStartTime, and proposedEndTime as required by UpdateBookingRequestPayload.

3. Update processBooking usage in context.tsx and all callers to pass reason instead of rejectionReason, and proposed times when status is proposed.

4. Update client-side types to match UpdateBookingRequestPayload (status, reason, proposedStartTime, proposedEndTime).

5. Keep or strengthen UI validation:

   • Reject requires a non-empty reason.
   • Propose requires reason + valid proposedStartTime < proposedEndTime, both in the future.

Acceptance criteria

• No frontend code calls /bookings/{id}/process.
• Frontend sends PUT /bookings/{id} with the correct payload for confirm, reject, and propose flows.
• Confirm, reject with reason, and propose with times plus reason work without API errors.

Testing checklist

• Start backend and frontend locally.
• Confirm a pending booking via Approvals UI → backend receives PUT /bookings/{id} with { status: "confirmed" }.
• Reject a booking with a reason → backend receives { status: "rejected", reason: "<text>" }.
• Propose new slot → backend receives { status: "proposed", reason, proposedStartTime, proposedEndTime }.
• Verify UI state updates, and no console or network errors.
• Search repository for /bookings/${id}/process and confirm zero results.

[saknarajapakshe]

@MohamadNazik After backend PR #157 gets merged, do the changes to align with the backend by addressing this issue.
After that, we can remove PATCH /bookings/{id}/process from the backend.