perf(proxy): trim routes from stops/location response

[ai-tiro]

Closes #163

Stacked on #166 (fix/162-stopdetail-foreground-dup). Base is the stacked branch, not master. The change is pure Go (backend/) and independent of the mobile edits below it in the stack — no conflict.

What

The /api/v3/stops/location response used by the Nearby map carried a full per-stop routes array. The proxy now strips that array from the response for that endpoint only, before returning it to the client. All other endpoints keep their existing verbatim io.Copy passthrough.

trimStopsLocation decodes the envelope and the stops array as raw JSON messages, deletes only the routes key from each stop object, and leaves every other field — top-level (disruptions, status) and per-stop (stop_id, stop_name, stop_latitude, stop_longitude, route_type, stop_suburb, …) — byte-for-byte intact. On any structural surprise (not an object, stops not an array, a non-object stop, marshal error) it returns the body unchanged and ServeHTTP falls back to a verbatim copy, so the endpoint can never be broken by an unexpected upstream shape.

Measured size win

Real upstream body, Melbourne CBD (stops/location/-37.8136,144.9631?max_results=100&max_distance=500):

	bytes
before (with routes)	38978
after (routes stripped)	7535
reduction	80.7%

Verified by feeding the captured live response through trimStopsLocation directly. This matches the 38–41 KB figure in the issue and removes the field that dominates bytes-on-wire (departures are ~120 B–2 KB).

What I confirmed about client field usage (the critical safety check)

The mobile client does not consume routes from this endpoint:

• The nearby response deserialises into StopDto (mobile/core/network/.../model/StopDto.kt), which declares only stop_id, stop_name, stop_suburb, route_type, stop_latitude, stop_longitude — there is no routes field on the DTO at all. kotlinx.serialization is configured with ignoreUnknownKeys, so routes was already being silently dropped on-device.
• The mapper StopDto.toDomain() reads only those six fields.
• The Nearby pins render from those fields only. The bottom sheet's route list is fetched separately via the per-stop detail endpoint (stopDetailRepository.getStopDetail(...)), not from this response.

So trimming routes here is invisible to every current consumer.

What I tried that didn't work / alternatives considered

• Ask PTV to omit routes upstream (cheapest, no transform). Checked docs/ptv-timetable-api-v3-swagger.json: the stops/location op only exposes route_types, max_results, max_distance, stop_disruptions — no expand/include/exclude lever. PTV always returns routes. So a server-side strip is the only option.
• Side note while measuring: passing route_types=0,1,2,3 (comma-joined) to the live proxy returns an empty stops:[]; PTV wants repeated route_types= params. Not in scope here, just noting it tripped up my first measurement.

Testing

• cd backend && go build ./... && go vet ./... && go test ./... — all pass.
• New handler tests:
  • TestHandler_StopsLocationTrimsRoutes — asserts routes/geopath/route_gtfs_id are gone, all pin fields + disruptions/status survive, body is valid JSON and smaller.
  • TestHandler_NonStopsLocationPassthroughKeepsRoutes — a stops/{id}/route_type/{type}-style body that legitimately carries routes is returned byte-for-byte unchanged, proving the trim is scoped.
  • TestTrimStopsLocation_Fallbacks — malformed JSON, non-object top level, missing stops, non-array stops, non-object stop, and no-routes-present all return the body untouched.

Justification / caveats

• Scoped strictly to /v3/stops/location/ and only on a 200 response; everything else is untouched.
• The fallback-to-verbatim-on-any-surprise design means the worst case is "no size win", never "broken endpoint".
• No one-way-door changes. If a future client wants per-pin routes, it can use the detail endpoint (as the bottom sheet already does) or this trim can be removed.

🤖 Generated with Claude Code