BUG: Valid GPS coordinates on the equator / prime meridian (lat or lon == 0) are silently dropped during metadata extraction #1406

Summary

MetadataExtractor.extract_gps_coordinates() in backend/app/utils/extract_location_metadata.py silently discards valid GPS coordinates whenever latitude or longitude is exactly 0 — i.e. any photo taken on the equator or the prime meridian. The extractor returns (None, None) even though valid coordinates were present in the metadata.

Root cause

The fallback lookups use Python truthiness instead of explicit None checks. Since 0.0 is falsy in Python, a legitimate 0.0 coordinate is treated as "missing" and overwritten:

if not lat or not lon:                 # 0.0 is falsy -> branch taken even when valid
    ...
    lat = lat or gps.get("latitude")   # 0.0 or None -> None  (valid value destroyed)
    lon = lon or gps.get("longitude")

By the time execution reaches the correct if lat is not None and lon is not None: guard, the value has already been clobbered to None.

Reproduction (verified against current main)

Running the repository's own MetadataExtractor.extract_all() on realistic metadata:

The same drop happens for the alternative field names (lat/lon/Latitude/Longitude) and the nested exif.gps path, since they share the same x or ... pattern.

Impact

extract_all() is called during image upload at app/utils/images.py:275 to populate the location fields that back the location-based Memories / geocoded place-name feature. Photos captured on or crossing the equator (Ecuador, Kenya, Uganda, Indonesia, Brazil) or the prime meridian (UK, France, Spain, Ghana, Algeria) lose their location entirely and never appear in location Memories.

Scope / not a duplicate

• This is distinct from the existing memory-classification issues (date-vs-location tagging) and the geocoding feature request — it's an upstream extraction bug that drops the coordinates before any of that logic runs.
• I also checked the separate _extract_gps_coordinates() in app/utils/images.py: it parses GPS as DMS tuples and is not affected by this, so the fix is correctly scoped to extract_location_metadata.py.
• Note 0.0 is a genuinely valid coordinate; invalid values are already handled separately by the existing -90..90 / -180..180 range check, which this fix leaves intact.

Proposed fix

Replace the truthiness-based fallbacks with explicit is None checks so 0.0 is preserved while genuinely-absent values still fall through to the next source. I've already implemented this and validated it locally with unit tests covering the equator, prime meridian, Null Island, nested-EXIF, normal, out-of-range, and missing cases (all passing), with no regression to existing behavior.

@rohan-pandeyy I'd like to be assigned this — I have the fix and tests ready and can open a PR right away.