Split into frontend and backend keys for Google Maps API usage

[ngm]

We were using the same API key for both the client-side and server-side.

Google says 'Never use the same API key for client-side (mobile app, web app) and server-side applications.' (Google Maps Platform best practices: Restricting API keys – Google Maps Platform)

This allows us to restrict backend key via server IP address, and frontend key by HTTP referrer.

[ngm]

I'd prefer to have different keys for different environments, as it's easier to manage keys, but this is fine for now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[edwh]

Residual concern: HTTP referrer is unreliable

HTTP referrer restrictions on the frontend key are imperfect. Modern browsers frequently strip or modify the Referer header in cross-origin requests for privacy reasons (depending on Referrer-Policy, browser version, and extensions), so a key restricted this way may still be usable from other origins.

Alternative: full server-side proxy (no frontend key at all)

A stronger approach is to eliminate the frontend key entirely by proxying the Google Places Autocomplete and Geocoding calls through authenticated Laravel endpoints:

• GET /api/maps/autocomplete?input=... — calls Google Places Autocomplete API server-side
• GET /api/maps/place-details?place_id=... — calls Google Place Details API server-side

Both endpoints sit behind the existing auth middleware, so only logged-in users can trigger Google API calls. The frontend vue-google-autocomplete component would be replaced with a lightweight custom Vue autocomplete that calls our proxy. gmap.blade.php (which loads the JS SDK with the key) would be removed entirely.

This works cleanly for restarters.net because:

• The only pages that use Places Autocomplete (group/event create and edit) already require authentication
• The backend key is already IP-restricted (from this PR)
• The map display on those forms already uses Leaflet, not Google Maps, so there is no JS SDK needed for rendering

Google's own security guidance confirms: for the Maps JavaScript API the key is inherently visible in source, but the Places and Geocoding APIs have REST interfaces that can be called server-side — keeping the expensive, per-request APIs completely off the frontend.

This PR implements the key-split as a straightforward improvement. The full proxy approach would be a follow-on.