Is your feature request related to a problem? Please describe.

Loading GBFS geofencing zones via the runtime updater is too slow and significantly delays OTP startup. The current implementation processes zones at every startup, which is wasteful for deployments with relatively static zone data.

Additionally, GBFS geofencing zones are still evolving in the spec, and OTP's implementation is experimental. We need a way to iterate on improvements to zone handling without affecting existing usage of the runtime updater.

In the Norwegian datasets we encounter operators with 10s and even 100s of zones in each city they operate. We can debate whether this is bad data, or bad implementation, but we still need a way to see how these zones function in a real life deployment, so we can make informed decisions about the path forward. Hence why we want to do this as a sandbox.

Goal / high level use-case

Enable baking GBFS geofencing zones into the graph at build time, avoiding external dependencies and zone processing at runtime. This supports faster startup for production deployments where zone data doesn't change frequently.

Describe the solution you'd like

A new sandbox feature GbfsGeofencingBuildTime that:

1. Reads GBFS feed URLs from build-config.json under a gbfsGeofencing section
2. Fetches geofencing zones during graph build
3. Applies zones to street edges
4. Persists the restrictions with the serialized graph

Describe alternatives you've considered

• Optimizing the runtime updater - addresses symptoms but not the fundamental issue of repeated zone loading.
• Caching zones between restarts - adds complexity and cache invalidation challenges

Additional context

• Follows established sandbox patterns
• Can reuse or start with a copy existing zone loading and and vertex updater
• Does not replace runtime updaters - both can coexist for different use cases
• Zones remain static until graph rebuild