## Fix: upsert no longer rewrites `position` on existing records
### Problem
`createX(..., upsert: true)` resets the `position` of records that
resolve to an **update**, even when the payload doesn't include a
`position`.
The create-many/upsert runner backfills `position` (to `"first"`) in
`computeArgs` over the **whole batch**, before records are split into
insert vs update. So existing rows get a freshly recomputed `position`
written on every upsert. For callers that re-upsert their full dataset
on a schedule (e.g. a daily sync), this rewrites `position` for every
record on each run and drifts the values steadily negative — and it
floods audit/event logs with position churn.
The dedicated `updateOne`/`updateMany` runners already pass
`shouldBackfillPositionIfUndefined: false`; the upsert path did not.
### Fix
Only backfill `position` for records that are actually inserted:
- `computeArgs` now passes `shouldBackfillPositionIfUndefined:
!args.upsert` in both the create-many and create-one runners, so
undefined positions are left untouched on upsert.
- `performUpsertOperation` backfills `"first"` positions for
`recordsToInsert` only, **after** categorization, via
`RecordPositionService`.
Explicit `position` values (`"first"`, `"last"`, or a number) in the
payload are still honored. Plain (non-upsert) create behavior is
unchanged.
### Behavior
| Scenario | Before | After |
|---|---|---|
| Upsert updates existing row, no `position` sent | `position` rewritten
| `position` untouched |
| Upsert inserts new row, no `position` sent | gets `"first"` | gets
`"first"` (unchanged) |
| Explicit `position` on upsert | applied | applied |
| Plain create | unchanged | unchanged |
Marie
e334551da9