fix(request): use update_columns:[] on nested target on_conflict (bug-087)

[mosoriob]

Summary

• POST /modelconfigurations, /modelconfigurationsetups, /datasetspecifications with relation fields (hasInput/hasOutput/hasModelCategory/hasPresentation) returned 400 null value in column "label" when the client linked an existing target by id alone.
• buildJunctionInserts emitted on_conflict.update_columns:['label'] on the nested target-entity insert. With nestedData = {id} only, on Hasura PK conflict the existing target row got UPDATE label=NULL and tripped the not-null constraint. Outer junction insert already used update_columns:[]; the inner inconsistency was the bug.
• Switch nested target on_conflict.update_columns to [] for link-or-noop semantics on existing target rows. New target rows still insert with all supplied fields. Renames remain the responsibility of the target's own PUT endpoint.

Evidence

Reproduction matrix (5 hypotheses, see dynamo-experiment-may/tests/modelconfig_writepaths_results.json):

• H1 minimal POST (no relations): 201
• H2 POST hasInput:[vp_id] string: 400 null label (this bug)
• H3 setup POST id-only objects: 400 null label
• H4 datasetspecifications POST hasPresentation:[vp_id]: 400 null label
• H5 POST with full nested DS objects (label included): 201 — confirms cause: H5 supplies label so the on_conflict update is a no-op

Test plan

• npm test (vitest): 188 passing
• Updated existing assertion in src/mappers/tests/request.test.ts Test 1 (was codifying the bug)
• Added two regressions covering hasInput:["id"] (string form) and [{id}] (object form), each asserting update_columns:[]
• Live integration: POST /modelconfigurations with hasInput:[""] returns 201 and GET shows the relation

Out of scope

PUT path with a VariablePresentation id still hits configuration_input_input_id_fkey because that FK targets dataset_specification. Separate FK type-mismatch issue; clients must pass DS ids, not VP ids.