test(integration): boot freight API in-process across parallel shards

The suite drove a containerized freight API, so every code change needed an
image rebuild before a test could see it, and there was no way to attach a
debugger. Files also ran strictly in sequence against one shared database,
which is the root of the warm-stack gotchas the README documents: stowaway
paid bookings climbing back aboard, a short consist on the fifth file.

The freight app now boots inside each vitest worker from dist/, and each
worker owns a whole shard of the topology - its own database, payment API,
gateway mock and broker vhost - so nothing mutable is shared and files run
in parallel. Full suite drops from roughly 20 minutes to 196s at 4 shards.

- main.ts exports createFreightApp() so the harness applies the same prefix,
  pipes, filters and interceptors as production instead of replaying them by
  hand; self-start is guarded by require.main so the Dockerfile CMD still boots
- booking-window tick cadence is env-driven (BOOKING_WINDOW_TICK_CRON), */1 in
  the suite, */10 unchanged in production
- prepare-shards.mjs seeds a template database (boot seeders, then the SQL
  fixtures that depend on them) and clones it per shard; it.mjs re-clones on
  every run, so each run is hermetic
- gateway mock and payment API are generated per shard: the mock keeps modes
  and orders process-global and 20 of 25 specs reset it in beforeAll, and the
  inbound CBE bill query has to reach one specific shard's app
- poll() samples every 250ms instead of 2000ms, keeping the caller's deadline
- authz.it.ts seeds its own invoice; it previously read another spec's leftover
  and returned early, which silently passed on a pristine database

Known: an unlocked MAX(sequence_no)+1 in train-scheduling.service.ts races
under concurrent allocation and leaves a short consist, so 1-3 specs fail
intermittently. Pre-existing and reproduces at the production tick cadence.

apps/edr-freight-api/src/modules/train-scheduling/booking-window.service.ts

@@ -91,7 +91,16 @@ export class BookingWindowService implements OnModuleInit {
   // 10-second cadence: every transition is derived from persisted timestamps
   // and applied idempotently, so a finer tick only shrinks the lag between a
   // deadline passing and the phase actually moving (was a full minute).
-  @Cron('*/10 * * * * *', { name: 'booking-window-tick', timeZone: BATCH_TIMEZONE })
+  //
+  // Overridable because that lag is the integration suite's pacing floor: every
+  // window phase, wagon allocation and expiry it waits on lands on this tick, so
+  // a 10s cadence costs ~5s of pure latency per wait across a few hundred waits.
+  // The suite runs it at `*/1 * * * * *`. Read at class-definition time, so the
+  // env var must be set before the module is imported.
+  @Cron(process.env.BOOKING_WINDOW_TICK_CRON ?? '*/10 * * * * *', {
+    name: 'booking-window-tick',
+    timeZone: BATCH_TIMEZONE,
+  })
   async tick(): Promise<void> {
     if (this.ticking) return;
     this.ticking = true;