Concurrent-write integration coverage that validates the W10 fix-C
reconciliation pattern carries over correctly to the
/api/workouts/batch endpoint:
- Two batches with overlapping (userId, source, externalId) tuples
posted in parallel resolve to exactly one DB row per tuple (the
composite unique index enforces it; createMany.skipDuplicates
absorbs duplicate-key conflicts).
- Each response body's per-entry envelope sums to its own
aggregate counts — the invariant the iOS sync cursor relies on
to checkpoint correctly.
- Aggregate inserted counts across both responses equal the row
count actually present, cross-validating that createMany.count
is the truth source rather than the older
'stored vs not-stored' diff (which was a no-op under standard
Postgres semantics because every attempted row IS in the DB
after the call, written by whichever batch won the race).
- A two-batch shared-key fixture asserts the shared tuple lands
exactly once across both responses.
Also adds workouts and workout_routes to the integration suite's
truncate list so beforeEach() actually clears them between tests
rather than relying on CASCADE from users.
