Build an Uber-style ride-share app with realtime tracking and surge pricing

Build an MVP ride-share app (Uber-style).

Stack: Next.js + Tailwind + Supabase (auth, Postgres, Realtime) + Mapbox GL JS (or Leaflet as fallback).

Roles & flows:
- Rider: enter pickup + destination (geocoded address or pin drop), see fare estimate before requesting, request ride, watch driver approach in realtime on the map (car icon rotates to heading), see ETA countdown, rate + tip after trip.
- Driver: toggle online/offline, receive ride request with pickup distance + fare preview, accept/decline (30s timeout → reassign), get turn-by-turn destination, swipe to start trip / complete trip, see earnings summary.

Realtime architecture (critical — explain this in the schema review):
- Use a Supabase Realtime channel per active ride (channel name: `ride:{ride_id}`).
- Driver broadcasts location updates via channel messages every 3 seconds (lat, lng, heading, speed). Do NOT write every update to the database — only persist location on status changes (accepted, arrived at pickup, trip started, trip completed).
- Rider subscribes to the channel and renders the driver marker. Interpolate between updates with requestAnimationFrame for smooth motion.
- Ride status changes (requested → matched → arriving → in_progress → completed → rated) use Supabase Postgres changes (Realtime) on the `rides` table so both rider and driver UIs update instantly.

Fare calculator:
- Base fare: $2.50 + $1.20/km + $0.35/min (make these config constants, not magic numbers).
- Surge pricing: query open ride requests vs. available drivers in a geohash cluster. If ratio > 2:1 apply 1.5x, > 4:1 apply 2.0x. Show surge multiplier to rider BEFORE they confirm.
- Estimate uses straight-line distance × 1.3 as a road-distance approximation.

Driver matching:
- On ride request: query drivers WHERE status = online AND current_location is within 5km (use PostGIS ST_DWithin or a simple lat/lng bounding box for the MVP). Rank by distance. Offer to the closest driver first. If declined or timed out (30s), offer to the next.

Schema must include: users (with role enum), driver_profiles (vehicle info, rating, online status, current_location as geography), rides (status enum, pickup/destination points, fare_estimate, final_fare, surge_multiplier, timestamps for each status), ratings, and a ride_payments table.

Seed data: 5 drivers with vehicle info, 3 sample completed rides with ratings.

Build order: (1) show me the schema + realtime channel design and WAIT for approval, (2) auth + role routing, (3) rider request flow + fare estimate, (4) driver matching + accept/decline, (5) realtime tracking map, (6) trip completion + rating, (7) earnings/history views.

Phase 2 roadmap (don\'t build yet, just outline): scheduled rides, multi-stop trips, driver heat map, ride sharing (pool), in-app messaging, and promo codes.

Tip: the realtime architecture is where Uber clones break. Broadcasting location on a channel (not writing every GPS ping to Postgres) keeps it fast. Approve the schema and channel design before any code gets written.