Server-side filtering and pagination for bookings

[shockalotti]

Requested in #15.

The bookings page offers Mine/All and Upcoming/Past and nothing else. There is no filter by event type, host or status, and no search. On a busy workspace Upcoming is an undifferentiated scroll.

Why this isn't just adding dropdowns

GET /v1/bookings (internal/handler/booking_handler.go) has no pagination and no limit. It loads every booking the caller can see via ListByHost/ListAll, then issues follow-up queries whose IN clause contains every booking id returned, against a pool capped at MaxOpenConns(1).

The MCP tool list_bookings (internal/handler/mcp.go) already accepts exactly the filters being asked for (status, date_from, date_to, event_type_id, host_id) but applies them in Go after loading everything. So the filter vocabulary exists, is only reachable by an LLM, and doesn't reduce the query cost.

Client-side filtering would make the page feel faster while making it heavier and leaving both problems in place.

Scope

• Push filters into SQL in the booking service: event type, host, status, date range
• Pagination (limit + cursor or offset); filtering without a limit is still an unbounded query
• Expose them as query params on GET /v1/bookings
• Point the admin bookings page at them
• Point MCP list_bookings at the same path and delete its Go-side filtering
• Team filter, resolved through team_members (see caveat below)

Team filtering caveat

Teams are a real entity (teams, team_members, CRUD at /v1/teams/*, admin page at /teams), so a team's bookings are the bookings hosted by its members. No schema change needed.

But event_types.team_id exists and is only ever written by the demo seeder. The host-roles model made a team a one-click way to populate event_type_hosts, so the association lives on the people, not the event type. Consequence: someone in two teams has their bookings appear under both. Acceptable for now; recording the team on the event type properly is separate, larger work.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[shockalotti]

Shipped on main in c1d6cb0, with review fixes in 6e4657b and 56b42ef.

Filters (event type, host, team, status, date range, upcoming/past), ordering and pagination all run in SQL now, shared by GET /v1/bookings and MCP list_bookings. Two defects fell out of doing it properly: status=cancelled could never match anything on either surface, and the host filter missed meetings a person attends but doesn't lead.

Migration 00056 adds the indexes that make paging actually cheaper rather than just returning less; without them every listing still sorted the whole matching set to hand back one page.