[Bookings] Refactor caching strategy to handle stale data cleanup for all filters

[irfano]

Description

This PR addresses a data consistency issue where stale booking data could persist in the local cache when applying filters.

Previously, when fetching filtered bookings, we used a simple insertOrReplace strategy. This updated existing bookings but failed to remove bookings that were no longer present in the server response (e.g., deleted bookings or bookings that no longer matched the filter).

While we had previously addressed this issue specifically for Today and Upcoming tabs (#15022), this fix extends that same robust cleanup logic to all filter types. It uses a single optimized SQL query to:

1. Identify local bookings that match the current filter criteria.
2. Delete those that are missing from the fresh server response.
3. Insert/Update the new bookings.

Pagination & Data Sync Strategy To ensure data integrity, we clear the entire cache for the active filter when refreshing the list (page 1). Why clear pages 2, 3, etc.? Without backend support for deleted items, we can't reliably sync a shifting list client-side.

• The Risk: If a new booking is added, items shift from Page 1 to Page 2. If we only update Page 1, our logic would see the shifted item as "missing" from Page 1 and delete it, causing accidental data loss.
• The Solution: We prioritize data accuracy over retaining offline data for older pages.

Test Steps

1. Make sure you have some bookings in the Today and Upcoming tabs
2. Launch the app
3. Go to Today and load the bookings
4. Trash one of the booking from the Today tab via the web
5. Refresh the Today tab in the app
6. Verify the booking was removed
7. Repeat 3-6 for the All tab.

Images/gif

Before

https://github.com/user-attachments/assets/9f328a8d-1431-4eef-addd-62a7ca50723e

After

https://github.com/user-attachments/assets/fbbe07b5-6429-4098-8cc8-15da490129f2

• [x] I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.