The booking list queries future and past in parallel with one time boundary

The portal booking page shows two sections. Upcoming bookings at the top sorted by start time ascending — the next meeting first. Past bookings below sorted by start time descending — the most recent first. The query function creates a single Date object and uses it as the boundary for both queries. Upcoming bookings have a startTime greater than or equal to now. Past bookings have a startTime less than now. Both queries run inside a Promise.all call so they execute in parallel against the database. The past query is capped at ten results because scrolling through months of old meetings has no value — the client only needs to reference recent ones. The upcoming query has no limit because every future booking matters. Both queries are scoped to the client's ID. The function first resolves the client record from their Clerk authentication ID, then uses that internal ID to filter both booking queries. If the client record does not exist, the function returns two empty arrays immediately without touching the database. The same pattern appears in other portal queries. Projects, sessions, goals, and invoices all resolve the client by clerkId first, then scope every subsequent query to that client's ID. No query in the portal can return data belonging to another client because every query chain starts with the same authentication lookup. The booking split is a small detail but it reflects a broader principle in the portal — do two fast queries in parallel rather than one flexible query that the frontend has to sort and split. The database handles the filtering. The component receives exactly the shape it needs.