## 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 |
groupBy fix: when a group's dimension value is NULL, we need to adapt
the raw sql (stage: NULL -> stage IS NULL)
typeMapper fix: a graphql type should be made non-nullable if was
indicated so + does not have a default value. our check on not having a
default value was limited to having a null defaultValue instead of
having a null or undefined defaultValue. This is a breaking change, but
all the queries that were providing a null value for these args were not
functioning anyway, and luckily in the FE we declared all queries adding
a `!` already.
## Introduction
After enabling flag by default got following errors:
```ts
Test Suites: 48 failed, 1 skipped, 97 passed, 145 of 146 total
Tests: 499 failed, 1 skipped, 644 passed, 1144 total
Snapshots: 61 failed, 133 passed, 194 total
Time: 363.226 s
Ran all test suites.
```
## From
<img width="2952" height="1510" alt="image"
src="https://github.com/user-attachments/assets/7e3b20c6-2552-40a7-90bb-2d7b3002c895"
/>
## To
<img width="3134" height="1510" alt="image"
src="https://github.com/user-attachments/assets/4fc9ada4-3c14-4333-a1db-11daf87db8d6"
/>
There's a huge test bundle in the latest shard that we could split up
## Notes
- Set as failing morph relation field rename as for the moment we do not
handle relation field mutation
- fixed the object update and creation validation adding label
identifier field metadata id checks
- and more
Some integrations tests are still on the v1 ( they have before and after
all disabling and re-enabling the flat ) but mainly we now have more
coverage on the v2 than the v1.
Mainly related records, uniqueness have to be migrated the v2 and so
tests too
Marie