Expose next bus departures and route search as REST APIs

[tiankaima]

Problem

The bot currently fetches /api/bus and implements route filtering, campus matching, departed/upcoming filtering, per-route grouping, next-trip detection, and display-oriented stop-time handling locally.

Server code already has richer bus domain helpers and MCP tools for this, but they are not exposed as normal REST APIs for bot/CLI/mobile clients.

Proposed server-side feature

Expose REST endpoints backed by existing bus service helpers, for example:

• GET /api/bus/routes?originCampusId=...&destinationCampusId=...
• GET /api/bus/next?originCampusId=...&destinationCampusId=...&atTime=...&includeDeparted=...&limit=...&dayType=...
• optionally support campus name/alias lookup or a dedicated /api/bus/campuses discovery response.

The next-departures response should preserve concrete route variants instead of flattening everything into one merged route, and should include enough metadata for clients to mark the next upcoming departure when departed trips are included.

References

Server already has getNextBusDepartures, searchBusRoutes, buildApplicableBusRoutes, and MCP tools in:

• src/features/bus/lib/bus-service.ts
• src/features/bus/lib/bus-departures.ts
• src/lib/mcp/tools/bus-tools.ts

Bot duplicates this logic in internal/commands/bus.go, including route grouping and next-row highlighting.

Acceptance criteria

• REST clients can ask for next buses without downloading the full timetable.
• Multiple concrete routes for the same origin/destination are represented separately.
• Response includes departed/upcoming status and identifies or enables identifying the next upcoming trip.
• Existing /api/bus full dataset endpoint remains available for clients that need it.
• OpenAPI/schema docs include the new endpoints.