diff --git a/CHANGELOG.md b/CHANGELOG.md
index e1fa557..c27544a 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,6 +4,7 @@
 - **Plane markers no longer teleport across the antimeridian (ISS-124).** The follow-up to ISS-120's known limitation: a plane mid-crossing still used the snapshot's wrapped lat/lon (`positionAt` wraps every longitude into [−180, 180]), so its marker jumped +179.x → −179.x between polls — a visible 360° teleport on the map while its route line stayed continuous. `planesGeoJson` in `lib/mapData.ts` now takes the airport index (`airportsByIcao`, same parameter shape as `routesGeoJson`) and re-expresses each FLYING plane's longitude against its departure airport — the same anchor `greatCircleArc` keeps for its first sample — via a new module-private `unwrapLon(lon, prev)` (the ±360 shift until |Δlon| ≤ 180 that `unwrapLons`'s loop body already used; `unwrapLons` now calls it). The unwrap applies only when BOTH leg endpoints exist in the index, mirroring `routesGeoJson`'s guard exactly: a marker is unwrapped if and only if its line is drawn. Grounded planes, repairing planes and flying planes with a missing endpoint keep their raw wrapped position (unchanged behavior); non-crossing legs are byte-identical (no |Δlon| > 180 → the shift never fires). `components/Map.tsx` passes `airportsIndexRef.current ?? new Map()` at both call sites (`applyDynamic` and the source bootstrap in `ensureLayers`) — planes draw immediately at their wrapped position until the airport index loads, then unwrap.
 - **Tests.** Unit +6 in `lib/mapData.test.ts` (new "antimeridian marker unwrap" block on the real NZAA/NFTF pair): eastward crossing unwraps a mid-leg −179.5 to +180.5 against the origin's +174.8, westward (reversed pair) unwraps below −180, and — the key invariant — every sample of `greatCircleArc(NZAA→NFTF)` fed back as a WRAPPED snapshot position comes out exactly on that arc's own sample, so marker and line agree frame to frame; grounded planes keep their raw coordinate, a flying plane with a missing endpoint stays wrapped (no line drawn either), and non-crossing legs are untouched. E2E +1 in `e2e/map-interactions.spec.ts`: the starter is relocated to Auckland via a fewest-legs chain over `/api/airports` (each hop ≤ 3400 km — within the ATR72's guaranteed range even in worst-case headwind; the tank is topped for free with the `set-fuel` hook before every dispatch so auto-refuel costs nothing), then a hook-created NZAA → NFTF package is loaded and flown at scale 1000 while the marker's longitude is sampled from the planes source every ~500 ms (real time) until the server reports landing — no two consecutive samples may differ by ≥ 180° (the teleport), some sample must sit on the east world copy (lon > 180, proving the crossing was actually traversed unwrapped rather than skipped), and the sampled span must exceed 4°. The plane chains back home afterwards so the other specs start from the canonical state.
 - **E2E fix (CI run 176).** The new antimeridian test failed deterministically in CI — not a marker bug, but a query trap: MapLibre's `querySourceFeatures` only returns features in LOADED tiles, and GeoJSON sources load per viewport tile; the default camera sits over Europe while NZAA/NFTF are in the Pacific, so the plane feature never appeared in queries and the "flying" poll timed out (the same pattern passes for EDDF→LEMD because that leg is inside the default view). The test now fits the camera over both endpoints first via `fitToAirports` (copied from `e2e/hover.spec.ts`, including its ISS-120 unwrap so a ±180-straddling pair bounds the Pacific, not the Atlantic) before polling and sampling. Pollution guard: relocation + crossing now run in a `try/finally` whose cleanup ALWAYS runs — it waits for any in-flight leg to land (scale 1000), then chains the plane back to EDDF from wherever it is, so a failed poll can no longer leave the starter FLYING and 409-cascade into the eleven later specs' fly-home helpers (the run-176 cascade). The dispatch POST's status is now checked explicitly with a clear message instead of a bare `expect(...).toBe(200)`. Unit +1 in `lib/mapData.test.ts` pins the exact feature properties the e2e `starterMarker` matches on (`properties.id === 'plane-starter'`, `properties.flying === true`).
+- **E2E fix (CI run 177).** The antimeridian test still failed — again not a marker bug: by dispatch time the test's page had been alive ~3 min through the relocation chain, and under dind load the browser's state feed can go stale (the SSE fallback in `lib/useGameState.ts` only re-arms polling on stream error or a one-shot 5 s silence check at connect), leaving the planes source frozen on an old FLYING frame from a relocation hop — which fooled the "wait for flying" poll and made every sampled longitude a stale pre-crossing value (continuous, all ≤ 180, never > 180). The test now reloads the page after relocation (server state persists; on the fresh page only the crossing leg can ever produce a flying frame), and the sampling loop gains a freshness gate: a sample is recorded only if its marker position is within ~700 km of where the SERVER snapshot says the plane is (~5 s of flight at ×1000 — haversine is ±360°-periodic in Δlon, so wrapped server lon vs unwrapped marker lon compare directly), so a frozen frame can no longer pass continuity vacuously; `starterMarker` now also returns latitude for that check. Pre-existing flake fixed in the same run: `e2e/queue.spec.ts`'s chain-refuel lower bound loosened from `1.4 × required2` to `1.3 × required2` — under dind load the post-departure snapshot can land ~0.1 × required2 into leg 2's burn (observed miss: 0.07 %); a wrong top-up level still lands far below the bound, and the exact level remains pinned by the upper bound plus the rep-discounted cash assertion.
 
 ## v0.57.0 — 2026-09-22 19:19
 - **Push updated state to clients over SSE (ISS-129).** Clients no longer rely on pure polling for live updates: new `GET /api/events` streams full game-state snapshots as Server-Sent Events — the current snapshot immediately on connect, then one after every sim tick (~1 s), so the UI updates push-driven even while idle. New module `lib/sse.ts` is a tiny in-process fan-out registry (`subscribe(fn)` → unsubscribe, `broadcast(text)` with per-subscriber try/catch) — the three process-wide singletons (this subscriber set, the sql.js DB promise (`getGameDb`), and the tick lock (`withLock`)) live on `globalThis`: Next.js can load a module more than once per process (instrumentation.ts and route handlers get separate module instances), so plain module-level state would give each layer its own registry/DB/lock, and background-tick pushes would never reach route-handler subscribers. The broadcast hook lives in `tickNow()` in `lib/sim/engine.ts`: after each locked tick on the singleton path it serializes via the SAME `getStateSnapshot()` that `GET /api/state` returns (no duplicated serialization) and pushes to all subscribers; failures are logged, never fatal. Action mutations reach other clients within one background tick (~1 s); the acting client still gets its immediate post-action snapshot from the POST response as before. The SSE route (`app/api/events/route.ts`) sends `Content-Type: text/event-stream`, `Cache-Control: no-cache`, `Connection: keep-alive` and `X-Accel-Buffering: no` (prod sits behind Traefik), plus a `: ping` heartbeat comment every 15 s so idle proxies don't drop the connection; snapshot-first-then-subscribe ordering guarantees events are strictly ordered by sim clock, and stream cancel unsubscribes + clears the heartbeat; broadcast pushes are wrapped in `data: <json>\n\n` SSE frames at the route (matching the initial snapshot). Client (`lib/useGameState.ts`): one `EventSource('/api/events')` per page — onmessage parses the full snapshot into the shared state (same shape as today); polling stays as an automatic fallback: if no event arrives within 5 s of connect, or on a stream error, the old poll loop starts (immediate catch-up fetch + interval), and it stops again when fresh events flow. EventSource's native reconnect is relied on — no custom reconnect framework. `/api/state` behavior is unchanged (still ticks-then-snapshots; polling remains fully functional).
diff --git a/e2e/map-interactions.spec.ts b/e2e/map-interactions.spec.ts
index d82e812..2469a41 100644
--- a/e2e/map-interactions.spec.ts
+++ b/e2e/map-interactions.spec.ts
@@ -392,19 +392,20 @@ async function chainTo(page: Page, fromIcao: string, toIcao: string): Promise<st
   return path;
 }
 
-// plane-starter's marker from the planes source: its longitude plus whether that frame is a FLYING one.
+// plane-starter's marker from the planes source: its position plus whether that frame is a FLYING one.
 // Extracted IN-PAGE because MapLibre feature geometry can be a lazy prototype getter that Playwright's
 // evaluate serialization drops (same trap as e2e/hover.spec.ts). The `flying` flag matters for the
 // sampling loop: a grounded frame snaps back to the raw airport coordinate (−175.1), which is the same
-// screen point but a 360° jump in raw data — only flying frames may be recorded.
-function starterMarker(page: Page): Promise<{ lon: number; flying: boolean } | null> {
+// screen point but a 360° jump in raw data — only flying frames may be recorded. `lat` feeds the
+// freshness gate below (a stale source frame sits far from where the SERVER says the plane is).
+function starterMarker(page: Page): Promise<{ lat: number; lon: number; flying: boolean } | null> {
   return page.evaluate(() => {
     const m = (window as any).__flightMap;
     if (!m || !m.getSource('planes')) return null;
     try {
       for (const f of m.querySourceFeatures('planes') as Array<{ properties?: Record<string, unknown>; geometry?: { coordinates: number[] } }>) {
         if (f.properties?.id === 'plane-starter' && f.geometry) {
-          return { lon: f.geometry.coordinates[0]!, flying: f.properties.flying === true };
+          return { lat: f.geometry.coordinates[1]!, lon: f.geometry.coordinates[0]!, flying: f.properties.flying === true };
         }
       }
     } catch {
@@ -478,6 +479,14 @@ test('plane marker stays continuous across the antimeridian (no 360° teleport)'
       }
     }
 
+    // Fresh page before the crossing leg: this test's page has been alive ~3 min (relocation chain) and
+    // under dind load the browser's state feed can go stale — a frozen planes source would then keep an
+    // old FLYING frame from a relocation hop, fooling the flying poll below and sampling stale lons.
+    // Server state persists across reloads; the plane is grounded at ORIGIN here, so on this fresh page
+    // ONLY the crossing leg can ever produce a flying frame.
+    await page.reload();
+    await waitForAirportCount(page);
+
     // The crossing package + dispatch.
     await setFuelFull(page, 'plane-starter');
     const pkg = await createPackage(page, ORIGIN, CROSS_DEST);
@@ -496,16 +505,20 @@ test('plane marker stays continuous across the antimeridian (no 360° teleport)'
     // Sample the marker's longitude while it crosses. Stop once the SERVER says landed; record only
     // FLYING frames — a grounded frame snaps back to the raw airport coordinate (−175.1), the same screen
     // point but a 360° jump in raw data, and could land between this loop's server read and source read.
+    // Freshness gate: the browser's source may lag server truth by a tick or two (SSE + tile re-render),
+    // but a FROZEN frame would otherwise pass continuity vacuously and never show the crossing — accept
+    // only frames within ~700 km of where the SERVER says the plane is (~5 s of flight at ×1000); haversine
+    // is ±360°-periodic in Δlon, so wrapped server lon vs unwrapped marker lon compare directly.
     const lons: number[] = [];
     for (;;) {
       const p = (await getState(page)).planes.find((x) => x.id === 'plane-starter')!;
       if (p.status !== 'flying') break;
       const marker = await starterMarker(page);
-      if (marker?.flying) lons.push(marker.lon);
+      if (marker?.flying && haversineKm(p.lat, p.lon, marker.lat, marker.lon) < 700) lons.push(marker.lon);
       await page.waitForTimeout(500);
     }
 
-    expect(lons.length).toBeGreaterThan(3); // a real flight window, not a degenerate one
+    expect(lons.length).toBeGreaterThan(3); // a real flight window of FRESH frames (stale ones are gated out above), not a degenerate one
     for (let i = 1; i < lons.length; i++) {
       expect(Math.abs(lons[i]! - lons[i - 1]!), `marker jumped between samples ${i - 1} and ${i}`).toBeLessThan(180); // the ISS-124 bug
     }
diff --git a/e2e/queue.spec.ts b/e2e/queue.spec.ts
index 5d59e15..0f43891 100644
--- a/e2e/queue.spec.ts
+++ b/e2e/queue.spec.ts
@@ -572,7 +572,9 @@ test('a drained tank is topped up before a chained leg at exactly the rep-discou
   // Exact fuel equality is impossible — this snapshot lands after leg 2's departure burn; the exact top-up level × rep-discounted price is pinned by the cash assertion below.
   const fuel = s.planes.find((x) => x.id === 'plane-starter')!.fuel;
   expect(fuel).toBeLessThanOrEqual(target); // can only have burned since departure…
-  expect(fuel).toBeGreaterThan(1.4 * required2); // …and a wrong top-up level (≤ required2, or none at all) lands below this bound
+  // 1.3× not 1.4×: under dind load the snapshot can land ~0.1×required2 into leg 2's departure burn;
+  // a wrong top-up level (≤ required2, or none at all) still lands far below this bound.
+  expect(fuel).toBeGreaterThan(1.3 * required2);
   expect(s.account.cash).toBeCloseTo(cashBeforeChain - expectedCost, 6); // at exactly the rep-discounted cost
 
   // Let leg 2 finish so the next test starts from a known airport.