Nested input types in @mutation fields

Remove the NestingField arm of the structural-rejection switch.

In the per-field admission loop, when f is NestingField, recurse on nf.fields() applying the same arm checks (so a buried CompositeColumnField on INSERT still trips the R130 deferred rejection).

Reject nf.list() == true with Rejection.structural naming this item.

Reject @value on a NestingField carrier with a clear message (@value applies to leaf input fields, not nested input groupings; mark the leaves under '<name>' individually). When R188 lands and @value disappears, this rejection disappears with it.

Before partitioning, walk fields and project each NestingField to its admissible-carrier leaves with extraction rewrapped into CallSiteExtraction.NestedInputField(argName, accessPath, leafExtraction). The access path is the list of SDL names from input root to leaf (e.g. ["lokalisering", "landkode"]).

The partition (LookupKey vs Set) then runs over the flat-leaf list. valueMarkedNames (today a Set<String> of input-root SDL names) widens to Set<List<String>> keyed by access path so @value on a leaf under a nesting field partitions correctly. Update the upstream collection in MutationInputResolver to emit dotted-path keys.

setFields().stream()…​map(f → f.name()) consumers want the leaf’s local SDL name (for presence checks against the nested map) AND the access path (for wire fetch). Both are present on the leaf’s NestingField-wrapped extraction; emit-site refactor in step 4 reads both.

Descend into NestingField when constructing InputColumnBinding entries, so the binding records the leaf’s column and the leaf’s access path. fieldBindings then includes nested leaves under their access path, and the PK-coverage check at MutationInputResolver.java:501-519 works unchanged (it consumes fieldBindings.targetColumns().sqlName() ; the column identity, not the field name).

Replace the literal presenceLocal.containsKey($S) / valueMapLocal.get($S) codegen pattern with a helper that consumes a List<String> access path. For a single-segment path, the emitted code is identical to today. For a multi-segment path, the emitted code chains the presence walk down the path before the leaf read; at the leaf, containsKey decides whether the column is written, and the value (which may be null) decides what it’s written to: java if (in.containsKey("lokalisering")) { var outer = in.get("lokalisering"); if (outer instanceof Map<?,?> m) { if (m.containsKey("landkode")) { sets.put(t.LANDKODE, DSL.val(__m.get("landkode"), t.LANDKODE.getDataType())); } } } The presence contract honors the same absent-vs-null distinction at every nesting layer that top-level mutation inputs already honor:

Key absent at any layer → no claim about that subtree; skip every leaf under it.

Key present with null outer value (lokalisering: null) → no claim about the group; skip every leaf under it. (Reading 1 of the outer-null fork; the literal-symmetric "clear every column in the group" reading is rejected as a sharp edge with no forcing-function schema.)

Key present with a Map at the outer layer → descend; each inner leaf’s absent-vs-null is honored independently per the leaf-level rule below.

Leaf key absent → skip the SET write for that column.

Leaf key present with null → emit SET <col> = NULL (explicit clear).

Leaf key present with a value → emit SET <col> = <value>. This means sending lokalisering: { landkode: "NO", bynavn: null } writes landkode='NO', bynavn=NULL and leaves regionnavn untouched, matching the top-level absent-vs-null semantics. Document this contract verbatim in the user docs so the difference between an absent key, a null outer, and a null leaf is visible to consumers.

Apply the same refactor to the bulk-INSERT row walkers (in.get(rowIdx) becomes the row-local map; from there the same access-path walk produces the cell read) and to the SET-via-EXCLUDED upsert arm.

MapGroup today carries an SDL field name as the wire-format key. Either extend the record to carry an access path (default singleton) or replace the name with a path field. The MutationInputResolver pre-step (R94’s input-record validator surface) already recurses into nested input components via fromMap, so the validator side composes without change once InputColumnBindingGroup knows the access path.

Section in docs/manual/tutorial/05-mutations.adoc: "Grouping fields with nested input types". Show the EndreOrganisasjonInput / LokaliseringInput forcing-function schema verbatim, walk the resulting mutation call (mutation { endreOrganisasjon(input: [{ id, originalnavn, lokalisering: { landkode, bynavn } }]) }), and call out three things: (a) the nested grouping has no DML semantics ; it’s purely a wire-format ergonomics shape; (b) @field(name:) on a nested leaf targets the outer table; (c) absent-vs-null is honored at every nesting layer ; an absent outer key or a null outer value skips the whole group, a present outer with a Map descends and each leaf’s absent-vs-null decides whether the column is written and whether the write is NULL or a value. Worked example: lokalisering: { landkode: "NO", bynavn: null } writes landkode='NO', bynavn=NULL and leaves regionnavn untouched. The chapter has no current section on nested input shapes; insertion point is right after the multi-column @mutation(typeName: UPDATE) example.

Cross-reference from docs/manual/reference/directives/mutation.adoc: one paragraph in the "Input shape" subsection noting that nested non-@table inputs are admitted as a grouping shape, with a pointer to the tutorial chapter for the worked example.

No changes needed to directives/table.adoc (the nested grouping is not @table-backed) or to the diagnostics glossary unless step 1’s @value-on-NestingField rejection ships before R188 retires @value ; in which case the glossary gains one entry.

The Invariant #4 contract (MutationInputResolver.java:319-323) ; setFields() on UPDATE equals the @value-marked admissible leaves ; generalises: under nesting it’s the flat-projected @value-marked leaves in SDL declaration order with NestingField children expanded in place. Update the class javadoc text accordingly; the producing code holds unchanged because it reads the flat leaf list.

The access-path invariant for nested-leaf extractions (every leaf flattened out of a NestingField carries a CallSiteExtraction.NestedInputField whose access path’s first segment is the immediately-enclosing NestingField’s SDL name) is mechanically pinned by the sealed-variant carrier on the leaf’s `extraction slot and by the pipeline-tier coverage step 4 above.