feat(maintenance): manage maintenance tickets

[temps-code]

Objective

Implement maintenance ticket workflow for rooms, including ticket creation, status
transitions, room availability blocking, archiving of resolved tickets via soft
delete, administrative purge, and filtered list navigation.

MVP Metadata

• MVP Phase: Operations
• Module: maintenance
• Priority: Medium
• Type: Feature
• FR: FR-10, FR-16
• Branch Target: features

Acceptance Criteria

• Maintenance tickets can be listed and created for rooms in the active property.
• Tickets can be assigned/reassigned when supported by staff roles.
• A ticket can block room availability when blocks_availability is true.
• Blocking maintenance updates or clearly indicates the room maintenance state.
• Tickets can be resolved/cancelled.
• The expected room state after resolution is defined: automatic restore or explicit manual state change.
• Maintenance data remains scoped by property.

Soft Delete & Lifecycle

• Resolved or cancelled tickets can be soft-deleted (set deleted_at) to archive them. Active list only shows records where deleted_at IS NULL.
• Soft delete requires manager or administrator role.
• Soft delete is blocked at service layer if the ticket is open or in-progress with blocks_availability = true, returning a descriptive error.
• A confirmation modal is shown before soft delete.

Hard Delete (Purge — Administrator Only)

• Administrators can permanently purge a soft-deleted ticket from the recycle bin.
• Purge is blocked at service layer if the associated room is still in maintenance state due to this ticket, returning a descriptive error.
• A strict irreversible-action warning dialog is shown before purging.

Filtering

• Ticket list can be filtered by status (open, in-progress, resolved, cancelled).
• Ticket list can be filtered by blocks_availability (tickets actively blocking a room).
• Ticket list can be filtered by room.
• Empty/loading/error states are handled safely for all filter combinations.

Evidence Expected

• Link related commits and PRs.
• Include screenshots for UI changes when applicable.
• Include test/build evidence when implementation touches app/runtime code.