Freegle / Iznik / 24440

72%

push

circleci

fix(browse): sort & show "Closest" by the server distance so the order matches the badges

On the Nearby feed with "Closest" sort the list came out unsorted relative
to the distance badges (e.g. 8mi, 7mi, 13mi, 9mi, 9mi, 9mi). The client was
computing distance TWICE, from two different reference points, and ignoring
the authoritative per-post distance the server already returns:

  - the sort (sortBrowseMessages) ordered by getDistance(MAP CENTRE -> post
    lat/lng); the map centre is not the viewer's location and drifts as the
    map is panned/fitted, and
  - the badge (useMessageDisplay) showed milesAway(ME -> post lat/lng).

Different reference points => the list was genuinely ordered by distance-from-
map-centre while each badge showed distance-from-me, so it looked unsorted.

Since PR #932 the server stamps `distance` (blurred great-circle miles from
the viewer) on every browse-feed post - the same value the distance slider
already filters on. Use that single value everywhere:

  - sort "Closest" by m.distance (posts with no distance sort last, then fall
    back to recency), so the map centre is no longer needed by the sort; and
  - the distance badge now looks the server value up by id from the nearby
    store (distanceById getter) and prefers it, falling back to the client
    calc only off the feed (search, My Posts, ModTools).

Badge, list order and slider are now driven by one number and can't disagree.

Verification: sort/display/store specs updated + a regression check that the
list follows the server distance rather than a lat/lng re-derivation. Full
vitest suite green (13784 passing).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AsgvoSgfeUwBMBbxKJHSNy

12184 of 16105 branches covered (75.65%)

Branch coverage included in aggregate %.

61 of 63 new or added lines in 4 files covered. (96.83%)

129960 of 182366 relevant lines covered (71.26%)

37.94 hits per line