Streamline typed JSON parsing for trim compilation

[quinnj]

Summary

• parse typed structs through the StructUtils FieldSink{T} construction path
• let JSON own ordered PtrString field matching while StructUtils keeps a generic source contract
• keep scalar, collection, custom-style, raw-value, and write paths on their established behavior
• handle escaped object keys without leaking PtrString values to user code
• support inbound field rename and ignore=true tags under strict unknown-field handling
• add a public-entrypoint trim workload for typed, untyped, nested, mutable, tagged, error, lazy, and write paths
• require registered StructUtils 2.8.3

Why

This keeps typed parsing statically reachable for trim compilation without the interpreter plus per-struct :hot split proposed in #473. The implementation uses ordinary Julia specialization. Applications that want persisted first-use work can use a normal PrecompileTools.@compile_workload; no JSON-specific struct annotations or registries are required.

Performance

The comparison used Julia 1.12.6 and the same Parsers revision for upstream, this branch, #473's default interpreter, and #473 with :hot.

Case	This PR	Upstream	#473 default	#473 :hot
Four integers	0.147 us	0.129 us	2.70 us	0.488 us
String and Float64	0.111 us	0.101 us	1.80 us	0.554 us
Nested struct	0.696 us	15.6 us	15.1 us	3.07 us
Large Root	5.81 us	180 us	88.4 us	24.2 us
10,000 small structs	1.58 ms	1.28 ms	29.4 ms	8.34 ms
Wide-128, ordered	11.3 us	36.0 us	about 85 us	about 43.5 us
Wide-128, shuffled	42.0 us	35.4 us	about 85 us	about 43.5 us

The small-struct and shuffled-wide regressions are explicit. No measured row is more than 1.25x slower than upstream. JSON writing is effectively unchanged.

For 100 mixed DTOs, first use is 9.78 seconds here versus 16.48 seconds upstream, 10.65 seconds for #473's default interpreter, and 17.19 seconds for :hot. The cost scales linearly through 100 types.

A standard application workload gives:

• 16.44-second precompile versus 58.07 seconds for :hot
• 10.1 MB DTO cache versus 40.5 MB
• 44-49 ms cached load versus 204-220 ms
• 2.1 ms for the first 100 parses after restart versus 239-244 ms
• zero per-struct annotations

Validation

• typed and untyped scalars
• small, nested, nullable, tagged, mutable, wide, and bulk struct parsing
• typed arrays and dictionaries
• ordered and shuffled keys
• escaped-key equality, hashing, alias shadowing, and diagnostics
• custom dicttype, custom null values, unknown-field errors, and parse!
• JSON writing and custom lowering
• annotation-free safe-trim public-entrypoint executable
• annotation-free 100-DTO trim executable: 9.96-second build, 3.9 MB, successful execution

The trim test environment resolves registered Parsers 2.8.7, which includes the inference fix from #207. Full downstream application trim validation remains a pre-merge integration gate.

Co-authored by Codex

[codecov]

Codecov Report

❌ Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.49%. Comparing base (3af31c8) to head (edc4da0).

Files with missing lines	Patch %	Lines
src/parse.jl	93.33%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #475   +/-   ##
=======================================
  Coverage   90.48%   90.49%           
=======================================
  Files           7        7           
  Lines        1430     1452   +22     
=======================================
+ Hits         1294     1314   +20     
- Misses        136      138    +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.