Changelog
CatchTable search previously exposed only shops and total, and its offset input was declared as a number. Upstream /api/v6/search/list actually paginates with an opaque cursor: each page returns paging.hasMore plus a paging.nextOffset cursor string, and requesting any numeric offset other than 0 fails upstream with HTTP 500 (verified live 2026-07-07), so results beyond the first page were unreachable.
search output adds two fields: top-level next_offset (opaque cursor string, present only while more results remain — absent means the last page) and per-shop main_service (DINING for reservation-led shops, WAITING for waitlist-led shops; route WAITING shops through waiting-info before registering a waiting). The offset input is now the pagination cursor: send \"0\" (or omit it) for the first page and pass the previous response's next_offset unchanged for the next page. Numeric offset: 0 keeps working for the first page, but other computed numeric offsets were never functional — CatchTable rejects them with HTTP 500 — so callers that incremented offset must switch to next_offset. An unrecognized upstream main_service value fails the call with UPSTREAM_ERROR instead of being silently dropped.