Adding all the tests and fixes to the passengers app

docs/ISSUES.md

@@ -226,6 +226,20 @@ Two structural facts frame everything:
   `getExchangeRate(USD,ETB)=1.0` but `getRateOrThrow(USD,ETB)=100` → displayed fare and charged
   amount differ 100×. Matrix C2/C5.
 - **Fix**: one shared conversion routine with one rounding rule and one fallback policy.
+- **Resolution (booking-record coherence, UA-1b/UA-2/UA-3w)** ✅ — the stored booking record no longer
+  mislabels its amount. Every `booking.create` path (`bookings.service.ts` one-way/round-trip/
+  transit/round-trip-transit + the guest equivalents) now stores `currency: Currency.ETB` (the actual
+  currency of `totalMinor`/the ETB charge basis) instead of the display currency. The passenger-facing
+  amount stays in `displayCurrency`/`displayTotalMinor` (Birr for Ethiopian, DJF for Djiboutian, USD
+  for Other), and every read endpoint already prefers those. The portal `results/page.tsx` on-select
+  now carries the passenger-currency fare (`displayAmountMinor`) forward, aligning with the seats
+  page's already-`displayAmountMinor` fare logic. Net effect (agreed model **A**): the passenger sees
+  and is charged in their own currency; the internal charge basis stays ETB (the unit every downstream
+  calc — wallet debit, loyalty, refund, gateway conversion — already assumes), now honestly labeled.
+  Proven by `e2e-ui/specs/portal/ua2-usd-booking.spec.ts` and `ua3-djf.spec.ts` (UA-3w): `currency`
+  is `ETB` while `displayCurrency`/`displayTotalMinor` carry USD/DJF — red before the fix
+  (`currency` was `USD`/`DJF`), green after; UA-1 (ETB) unchanged. The deeper H-3 (unify
+  `getExchangeRate`/`getRateOrThrow`) and H-4 (branded Minor/Major units) refactors remain open.
 
 ### H-4 ✅ Conversion routines return different UNITS for the same money
 - **Where**: `displayMinorToChargeMajor`/`convertMinorToChargeMajor` return **major** units;
@@ -379,6 +393,13 @@ Two structural facts frame everything:
   `:124-132` blocks only same-train+same-route+same-day, so the same train can run two routes at
   overlapping times. Matrix H3/H4.
 - **Fix**: reject past `departureAt`; widen the overlap check to the train across all routes.
+- **Resolution (past departure)** ✅ — `schedules.service.ts` `createSchedule` now rejects a
+  `departureAt` in the past (`dep.getTime() < Date.now()` → 400) alongside the existing
+  `arrivalAt > departureAt` check. Proven by `e2e-ui/specs/backoffice/config-validation.spec.ts`
+  (BC-10): a 2020 departure → 400 while a future schedule still creates (red before the guard, green
+  after). Scoped to creation (an admin may still need to edit metadata on an already-departed
+  schedule via `updateSchedule`). The cross-route train double-booking overlap widening remains a
+  follow-up (not exercised by BC-10).
 
 ### M-5 🔎 Deletes ignore referencing bookings; one cascade is non-transactional
 - **Where**: station delete ignores bookings (`stations.service.ts:110-137`); seat-class delete