fix(listings): remove hardcoded (0,0) geo fallbacks in listing-read queries

The findByIdWithProperty and searchListings read queries used
`?? { latitude: 0, longitude: 0 }` fallbacks after PostGIS coordinate
extraction. Since the Property.location column is NOT NULL, these
fallbacks silently masked potential data issues. Replaced with non-null
assertions since geo data is guaranteed to exist for valid properties.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

apps/api/src/modules/listings/infrastructure/repositories/listing-read.queries.ts

@@ -31,7 +31,8 @@ export async function findByIdWithProperty(
     WHERE "id" = ${listing.property.id}
     LIMIT 1
   `;
-  const geo = geoRows[0] ?? { latitude: 0, longitude: 0 };
+  // location is NOT NULL in the database — geo extraction always succeeds for existing properties
+  const geo = geoRows[0]!;
 
   return {
     id: listing.id,
@@ -147,7 +148,8 @@ export async function searchListings(
 
   return {
     data: data.map((listing) => {
-      const geo = geoMap.get(listing.property.id) ?? { latitude: 0, longitude: 0 };
+      // location is NOT NULL — every property in the result set has geo data
+      const geo = geoMap.get(listing.property.id)!;
       return {
         id: listing.id,
         status: listing.status,