fix: keep error paths trim-verifier-clean

[quinnj]

fix: keep error paths trim-verifier-clean

Three error-message constructions made JSON.jl responsible for the majority of --trim verifier errors in downstream juliac builds. Measured on 1.14-DEV (juliac --trim=safe --experimental):

• an isolated parse+write workload (materializing parse, typed parse, json of Dict and struct): 474 → 56 verifier errors
• a real HTTP-server application graph: 374 → 205

The three sites (all in src/parse.jl)

1. jsonreadstyle — repr(::Symbol) in a throw: 165 errors from one line.
show(::Symbol) routes through the @nospecialized show_unquoted_quote_expr, which makes Base's entire Expr-show machinery (show_unquoted, show_block, show_generator, …) reachable from this error path — each with its own unresolvable dynamic call. Plain symbol interpolation (:$(unknown_fields)) prints identically for standard symbols and lowers to print(::IO, ::Symbol), a plain write.

2. unknownfielderror — repr(key) where key::PtrString: generic struct-show fallback.
PtrString has no print/show methods, so both repr and plain interpolation fall back to show_default (dynamic sizeof/fieldname sites under trim). Now converts PtrString → String explicitly — which also improves the message: the actual member name instead of a PtrString(Ptr{UInt8}…) struct dump. Keys can also be Int (array-into-struct with extra elements — covered by the existing @test_throws cases), hence the string(key) fallback method.

3. make fallback — "cannot parse $x" interpolated a LazyValue.
Its show renders through the array-display machinery (print_matrix etc.). This branch is unreachable in practice (all JSONTypes are covered above it); it now uses the same "cannot parse json" message as the sibling error paths at lines 360/506.

Behavior change

Error-message text only, in the three messages above. No API or parsing behavior changes. Full test suite passes, including the trim compile tests.

Not addressed here (follow-ups)

The 56 remaining workload errors are not JSON error paths: StructUtils field-matching (findfield/indexed_iterate) and write-closure dispatch (applyeach), and the Parsers BigFloat overflow-fallback digits machinery reached from parsenumber. Those want fixes in StructUtils/Parsers respectively — with them, materializing parse could graduate into the trim test workload's covered entrypoints (the carve-out documented in test/json_trim_public_entrypoints.jl).

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.42%. Comparing base (e5ef310) to head (eddf386).

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #472      +/-   ##
==========================================
+ Coverage   90.41%   90.42%   +0.01%     
==========================================
  Files           7        7              
  Lines        1419     1421       +2     
==========================================
+ Hits         1283     1285       +2     
  Misses        136      136              

☔ 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.