perf(gtfs): resolve lock contention in spatial queries

[AhmedAlian7]

Description

• closes Refactor GTFS Manager to Prevent DB I/O Under Read Lock #726

Location-based handlers (/stops-for-location, /routes-for-location, /trips-for-location) were acquiring a broad read lock (RLock()) that spanned the entire lifecycle of the request.

This PR mitigates the contention by enforcing narrow-scoped locking. Database operations are now strictly executed outside of the read lock, and handlers no longer wrap the entire request in a locking mechanism.

Changes

gtfs_manager.go

• GetStopsForLocation(): Refactored to manage its own concurrency internally. It now acquires an RLock() exclusively for the fast, in-memory R-tree spatial search (queryStopsInBounds()) and immediately releases it. Subsequent database queries are executed lock-free. The returned R-tree results are safe to utilize post-unlock, as the spatial index only mutates during static data reloads (which utilize a write lock).

API Handlers

Removed the encompassing RLock() / defer RUnlock() pattern from the following handlers, replacing them with precisely scoped locks for specific in-memory accesses:

• stopsForLocationHandler: Narrowly scoped locks for GetAgencies() and checkIfOutOfBounds().
• routesForLocationHandler: Narrowly scoped locks for GetAgencies() and checkIfOutOfBounds().
• tripsForLocationHandler: Narrowly scoped locks for GetAgencies() (within parseAndValidateRequest) and checkIfOutOfBounds().

Test (arrivals_and_departures_for_stop_handler_test.go)

• Updated 4 isolated test call sites that were manually wrapping GetStopsForLocation() with RLock()/RUnlock(). This prevents double-locking deadlocks since the method now handles its own internal locking.

[aaronbrethorst]

@AhmedAlian7 please fix the merge conflicts!