Clarify static lock ownership for vehicles-for-agency and conformance tests

[Adityatorgal17]

Summary

Static GTFS lock ownership around vehicles-for-agency was inconsistent, and some tests were calling static manager accessors without the caller-held RLock() they require.

Problem

vehiclesForAgencyHandler previously acquired GtfsManager.RLock() only for the initial FindAgency lookup and released it before continuing with the rest of the handler. VehiclesForAgencyID separately acquired the static lock internally.

That split lock ownership made the static read boundary unclear and inconsistent with the rest of the gtfs.Manager API, where static accessors generally expect the caller to already hold RLock().

Tests had the same issue:

• Direct calls to VehiclesForAgencyID did not consistently hold RLock()
• TestOpenAPIConformance_StaticEndpoints was reading static manager data without first acquiring RLock()

Expected Behavior

Static manager access should follow one consistent contract:

• Caller holds manager.RLock()
• Static accessor reads happen within that caller-owned lock scope

Issue Solved

• vehicles-for-agency now uses one explicit caller-owned static read-lock scope
• VehiclesForAgencyID now follows the same caller-locking contract as other static manager accessors
• Missing RLock() coverage was added to TestOpenAPIConformance_StaticEndpoints