M2: the full job lifecycle — chat, hiring, geocoding, quotes, bookings, reviews

Closes the funnel. Before this the product could match two people and then
stopped: `quotes`, `bookings` and `reviews` had tables and state machines and
nothing that wrote a row, the entry deck's right swipe was wired to an empty
handler, and every address resolved to the city centre.

Jobs tab and chat
- message router: thread, send, markRead, unreadTotal. A thread is a MATCH, not
  a job — one job with three interested pros is three private conversations.
- Current/Past segments derived from ACTIVE_JOB_STATUSES, job detail listing the
  pros who accepted, and the conversation itself with attachments.

Hiring from the deck
- A right swipe on the entry deck opened nothing. It now resolves "which job?"
  through a sheet — sign in, pick an open job, or post one — and calls the same
  deck.swipe the per-job deck does, so the open-request cap and row lock apply
  exactly once. Swipes are vetoable so closing the sheet returns the card.

Geocoding
- ST_Distance and ST_DWithin rank and filter every deck, and both operands were
  placeholders. Addresses now resolve through Mapbox (permanent=true, which is
  what licenses storing the coordinates), the server resolves points rather than
  trusting client-supplied lat/lng, and every stored point records how it was
  obtained. A `city`-precision base cannot reach the verification queue.

Quote -> booking -> review
- The commercial chain, minus payments. Accepting a quote is the only place a
  booking is created; confirming completion is what unlocks reviews and moves
  the pro's completed_jobs.
- Reviews publish double-blind with no sweeper: each is written with
  published_at already set to its embargo deadline and every read filters
  published_at <= now(), so it publishes itself. The second review pulls both
  forward. A silent counterparty cannot bury a bad review by never replying.

State machine changes, both deliberate
- booked -> matched: a cancelled booking is not a cancelled job.
- scheduled -> awaiting_confirmation: in_progress is optional, so a pro who
  never tapped Start can still say the work is done.

Test suite
- api tests ran files in parallel against one database and failed roughly one
  run in three on whichever file lost the race. Serialised, and three fixtures
  that grabbed "the first client" pinned to the seeded accounts.

Also includes work from a parallel session: admin verification queue, pro
public profile and reviews read path, notification sending, denormalised stats
recompute, search, and observability.

318 tests passing; typecheck and lint clean across 7 packages.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

packages/api/src/location.ts

@@ -0,0 +1,106 @@
+import { forward, GeocodeError, isConfigured, type GeocodeResult } from '@linkder/geocode';
+import type { LatLng, LocationInput, LocationPrecision } from '@linkder/shared';
+
+/**
+ * The one place a stored coordinate is decided.
+ *
+ * `job.create`, `pro.upsertProfile` and `user.updateLocation` all route through
+ * here, because a point that means one thing on a job and another on a pro
+ * profile makes `ST_Distance(p.base_location, j.location)` meaningless — and
+ * that expression is how this product ranks every deck.
+ *
+ * The important property: for a picked suggestion the SERVER resolves the
+ * coordinates. The client sends an id and a label, never a lat/lng. Before this,
+ * `job.create` wrote `input.location` straight through, so a crafted payload
+ * could put a job anywhere and an ordinary form could — and routinely did — put
+ * it at the city centre while the row claimed to be an address.
+ */
+
+export interface ResolvedLocation {
+  location: LatLng;
+  /** What the geocoder called this point. Written to the row's address column. */
+  addressText: string;
+  precision: LocationPrecision;
+  placeId: string | null;
+}
+
+export interface CityCentre {
+  lat: number;
+  lng: number;
+  name: string;
+}
+
+/** The fallback point, read once from env. Throws rather than guessing a city. */
+export function cityCentre(): CityCentre {
+  const lat = Number(process.env.NEXT_PUBLIC_CITY_LAT);
+  const lng = Number(process.env.NEXT_PUBLIC_CITY_LNG);
+  if (!Number.isFinite(lat) || !Number.isFinite(lng)) {
+    // Same reasoning as deck.showcase: an unset city silently makes every pro
+    // "out of radius", which looks like having no supply rather than a config
+    // mistake.
+    throw new Error('NEXT_PUBLIC_CITY_LAT / NEXT_PUBLIC_CITY_LNG are not set.');
+  }
+  return { lat, lng, name: process.env.NEXT_PUBLIC_CITY_NAME ?? 'the city centre' };
+}
+
+function centreFallback(label?: string): ResolvedLocation {
+  const centre = cityCentre();
+  return {
+    location: { lat: centre.lat, lng: centre.lng },
+    // Keep whatever the person typed. It is not a location, but it is a note to
+    // themselves and to the pro who eventually turns up.
+    addressText: label?.trim() || centre.name,
+    precision: 'city',
+    placeId: null,
+  };
+}
+
+/**
+ * Turn what the caller reported into a point we are willing to store.
+ *
+ * Never throws for a geocoding failure. A provider outage must not stop someone
+ * posting a job — it downgrades them to `city` precision, which every read
+ * surface already knows how to treat as "we do not really know where this is".
+ */
+export async function resolveLocation(input: LocationInput): Promise<ResolvedLocation> {
+  if (input.source === 'none') return centreFallback(input.label);
+
+  if (input.source === 'device') {
+    return {
+      location: { lat: input.lat, lng: input.lng },
+      addressText: input.label?.trim() || 'Current location',
+      // Never `exact`. A handset fix is metres out on a good day and a street
+      // away on a bad one.
+      precision: 'approximate',
+      placeId: null,
+    };
+  }
+
+  if (!isConfigured()) return centreFallback(input.label);
+
+  try {
+    /*
+     * Re-resolve from the label and keep the candidate whose id the caller
+     * picked.
+     *
+     * Mapbox Geocoding v6 has no retrieve-by-id, so a forward call on the same
+     * text is how the id gets turned back into a point. Costs one extra request
+     * per SAVE — not per keystroke — which is the right place to spend it: the
+     * alternative is trusting coordinates from the browser, and the whole reason
+     * this file exists is that we did that and the data was wrong.
+     */
+    const candidates = await forward({ q: input.label, limit: 10 });
+    const match = candidates.find((c: GeocodeResult) => c.providerId === input.placeId);
+    if (!match) return centreFallback(input.label);
+
+    return {
+      location: match.coordinates,
+      addressText: match.label,
+      precision: match.precision,
+      placeId: match.providerId,
+    };
+  } catch (error) {
+    if (error instanceof GeocodeError) return centreFallback(input.label);
+    throw error;
+  }
+}