fix: report an unknown field once, by the innermost strict that does not know it

[kawasima]

Part of #183 (item 1). Items 2–4 and item 5 follow in their own PRs.

Cause

Decoders.strict built its unknown_field issues before running the inner decoder and merged them with whatever the inner decoder returned, without looking at it. Every strict level therefore reported a field it did not know, whether or not a strict inside had already reported it:

• R000862: strict(discriminate("kind", {rect: strict(...)}), ...) gave unknown_field at /extra twice.
• R000863: strict(strict(object([a]), [a]), [a]) gave unknown_field at /b twice.

The specification (raoh-specification#24) leaves out only an unknown_field that an unknown-members check made at the member's path. A same-looking issue a user's decoder returns is still reported, and so is an issue of another code at that path (R000866). Issue does not say what made it, so filtering by path and code would also drop the user's issue. Decoders.strict is the only producer of unknown_field: MapDecoders.strict, JsonDecoders.strict and Combiner*.strict all delegate to it.

Change

• IssueList, the list behind Issues, records which issues an unknown-members check made. Such an issue sits in its slot inside a small wrapper record, so unmarked issues cost nothing, and appending copies the mark with the slot. add and merge keep the marks; rebase and resolve (Issues and IssueTree.map) now replace the issues through IssueList.replacedBy, which keeps them too. A list built anew from the issues, such as new Issues(new ArrayList<>(...)) in a user's decoder, has none.
• The mark is not visible: Issue is unchanged, Issues equality is List equality of the issues, and toJsonList and the other views read the issues only. It is read and written through net.unit8.raoh.internal.IssueProvenance, which IssueList implements, so no public API changes.
• Decoders.strict runs the inner decoder first, collects the paths of the marked unknown_field issues at the top level of its Err, and reports only the unknown fields at other paths, after the inner issues. Issues inside metadata, such as a one_of_failed issue's candidates, are not at the top level and do not count, as in the specification's flow.
• Why not a ThreadLocal sidecar or an origin component on Issue: the first is mutable static state reached from a decoder package, which the effect audit refuses; the second would make "which combinator made this" part of what an issue means, its equality and its serialization.

Tests

• JsonStrictTest: R000862–R000866 on the JSON boundary.
• NestedStrictTest: a user decoder's unknown_field is reported again; an inner strict's issues still count after flatMap rebases them to the outer path; a strict inside a oneOf candidate does not count; the inner result is kept when no field is unknown.
• IssueProvenanceTest: the marks survive add, merge, rebase, resolve (with and without issues in metadata), are gone from a list built anew, and do not affect equals, hashCode or toJsonList.
• Against develop's strict, R000862, R000863 and the flatMap case fail. Replacing the mark check with path and code alone fails the user-decoder case.
• mvn verify (effect audit included) and -Pnullcheck clean compile on Zulu 25 pass. The effect audit's new uses are filed under the existing reasons; the stale IssueTree#map -> List#copyOf approval is removed.

Review fix: what strict observes

Cause: running the inner decoder first also moved the point where strict reads the input's field names to after caller code. The specification orders the issues (the inner ones first), not the execution. With a mutable input, a decoder that removed extra made strict accept it, and one that added a member made strict report a field the input never had.

Same root: strict's decision must rest only on what strict itself observed.

• Raoh reading the input after caller code: every other combinator (recover, discriminate, nullable, withDefault, the Combiners, the Map / JSON / jOOQ field readers) reads the input once, before delegating. strict was the only one.
• strict trusting what caller code supplies: IssueList.copyOf believed any IssueProvenance implementation, so a user's decoder could forge "a strict made this" and hide its unknown_field from the outer strict.

Change: strict copies the names (new ArrayList<>(inputFields.fieldNames(in)), which keeps whatever names the InputFields gives) before dec runs, and builds its issues afterwards. The Javadoc now states this. IssueList.copyOf keeps marks only from the list IssueProvenance.unknownMembers makes. The new tests in NestedStrictTest failed before the fix. Effect audit: the copy is approved as reading configured field listings, and the iteration as iterating a list Raoh made.

🤖 Generated with Claude Code