The booking list at /bookings has always shown you the status of each reservation — pending, confirmed, active, completed, or cancelled. But "cancelled" alone doesn't tell the full story. Was it a schedule conflict? A better price elsewhere? A vehicle issue? Without context, a cancelled booking is just a disappeared slot.

That changes now. When you cancel a booking through the confirmation modal, you'll be prompted (optionally) to select a reason for the cancellation. Six common options are available: "Changed my mind", "Found a cheaper station", "Schedule conflict", "Charger location inconvenient", "Vehicle issue", or "Other" with a free-text field.

The reason selection is integrated directly into the CancelConfirmModal — it's not a separate form or step. The buttons are compact pill-style chips that snap into place, keeping the modal clean and fast. If you select "Other", a text input slides in below the options so you can type whatever you want. The whole flow stays in the same dialog.

Once a booking is cancelled with a reason, the cancelled booking cards on the bookings page now include a subtle danger-tinted banner beneath the status badge showing the reason. For example: "Cancelled: Schedule conflict". This gives providers and seekers alike immediate context for why a reservation was terminated.

Under the hood, the backend stores the reason in a new `cancel_reason` column on the `bookings` table. The `POST /api/bookings/{id}/cancel` endpoint now accepts an optional JSON body with a `reason` field. Backward compatible — existing callers that don't send a reason continue to work unchanged. The `GET /api/bookings/mine` endpoint now includes `cancel_reason` in every booking response.

This is a small feature with a meaningful transparency benefit. Whether you're a seeker reviewing your booking history or a provider analyzing cancellation patterns, the context is now captured and visible — no more wondering why that booking didn't go through.