Support Cloudflare visitor location headers with GeoLite2 fallback

[nicocart]

Feature request

Rybbit already has good Cloudflare-aware client IP handling via CF-Connecting-IP, but geolocation still appears to be resolved from the bundled GeoLite2 database.

For self-hosted Rybbit instances that are already proxied through Cloudflare, it would be useful to optionally prefer Cloudflare's visitor location headers when they are present, while keeping GeoLite2 as the fallback.

Cloudflare can provide headers such as:

• CF-IPCountry
• CF-Region
• CF-Region-Code
• CF-IPCity
• CF-IPLatitude
• CF-IPLongitude
• CF-Timezone

A possible resolution order could be:

Cloudflare visitor location headers (when present and trusted)
    ↓
GeoLite2 fallback

This would preserve the current fully self-hosted behavior for users who do not use Cloudflare, while allowing Cloudflare-backed deployments to use the geolocation data already calculated at the edge.

Why this could help
GeoLite2 data in a container image can become stale between image updates.
City / region attribution can differ noticeably from Cloudflare's current edge geolocation.
Rybbit already contains Cloudflare-specific proxy/IP handling, so this would complement the existing integration.
No ClickHouse schema change should be necessary because Rybbit already stores country, region, city, latitude, longitude, and timezone.

There is also an existing geolocation/proxy-related issue (#444), although that issue is primarily about resolving the correct client IP through a proxy rather than using Cloudflare's geolocation headers directly.

Suggested behavior
Keep GeoLite2 as the default/fallback provider.
If trusted Cloudflare visitor-location headers are present, use them for geo fields.
Avoid making Cloudflare a required dependency.

I would prefer to stay on the official Rybbit images rather than maintain a custom backend fork, so native support for this would be very helpful.