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

### 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:

```python
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.