conformance: add curated files of known-trap inputs

[justinhwang]

Summary

Seeded sampling gives coverage density but is blind to the specific inputs that have broken implementations. This adds six curated files of such inputs, 79 rows, each in exactly its group's record type so the existing runners pick them up by directory with no new runner code:

File	Rows	Subjects
inspection/curated.jsonl	17	the indexes the reference's CLI tests and test apps single out, plus two deleted-subsequence pentagons built by hand
hierarchy/curated.jsonl	8	the cellToChildren fixtures, a res 15 cell, pentagons at res 0 to 2
traversal/curated.jsonl	14	the CLI pairs and the upstream gridPathCells and gridDistance fixtures, including an invalid target and a resolution mismatch
localij/curated.jsonl	12	the CLI [25, 13] pair, the upstream cellToLocalIj fixtures, pentagon origins, an invalid origin
sets/curated.jsonl	6	the reference's compact_test1 and multipolygon_test3/4/5 cell lists, the six children of a pentagon, all 122 res 0 cells
regions/curated.jsonl	22	the SF fixtures with and without hole, the degenerate empty/point/line loops, prime meridian and antimeridian squares with and without hole, the complex antimeridian polygon, the polygons of h3 issues 136 and 595 and h3-js issue 67, both hemispheres at res 0 to 2, the two CLI polygons

The README lists every subject with its provenance (cli, tests, inputfiles or hand) and is the specification; the generator holds the same lists as tables and draws nothing for them.

Three small format consequences: the regions id is a name for these rows and the sets id is curated:<name>; the traversal subject is now the origin and target pair, since curated origins repeat; and a fill of no cells writes an empty multiPolygon sequence rather than the reference's single structure with no loops, which no sampled row had produced.

What the files found

• gridDistance ignores unused digits. The reference returns distance 0 and a one-cell path from 85283473fffffff to 85283472fffffff, whose digit 6 is not 7 and which isValidCell rejects. Pure Go does the same, so it is recorded as the reference's answer.
• A distance with no path. For the upstream fixture 8411b61ffffffff to 84016d3ffffffff the reference's gridDistance is 81 but gridPathCells fails with E_FAILED. Also matched.
• Classic polygonToCells fails by design on the polar band. The reference's own test asserts E_FAILED for the 85 to 89.9 degree band spanning 179 degrees of longitude, because maxPolygonToCellsSize underestimates the fill and the algorithm gives up when its buffer fills. Pure Go has no fixed buffer and returns the 260 cells at res 4. That is the better answer and a deliberate difference, so the polygon is not in the file; the README's regions section records why.

Every file outside the six new ones is byte-identical to before; the manifest changes only by the six new entries.

Test plan

• go test -count=1 -race -cover ./x/h3go/conformance/ passes at 100% coverage
• golangci-lint run ./x/h3go/conformance/... clean
• Regenerated with generate.sh; diff -r against the previous testdata shows only the new files and the manifest

🤖 Generated with Claude Code

[coveralls]

Coverage Report for CI Build 37543826666

Coverage remained the same at 100.0%

Details

• Coverage remained the same as the base build.
• Patch coverage: 1 of 1 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	4540
Covered Lines:	4540
Line Coverage:	100.0%
Coverage Strength:	2694426.45 hits per line

---

💛 - Coveralls