json/yaml typed loads pass the library's exception text through — the error names CLR types (Sharpy.List`1[J1.AppCfg], System.String)

[antonsynd]

Found by /verify-implementation plan-0ca7b7 (2026-09-26), measured @ 61bf20f with the built sharpyc; pre-existing at BASE acd1d40 unless noted.

json.loads[list[app_cfg]]('[{"name": 1, "max_conn": "x"}]') prints Err(Sharpy.JSONDecodeError: The JSON value could not be converted to System.String. Path: $[0].name | LineNumber: 0 | BytePositionInLine: 11.: line 1 column 12 (char 11)). The typed doors (Json.cs, Yaml.cs) wrap System.Text.Json / YamlDotNet ex.Message verbatim, and that text spells CLR type names (System.String, Sharpy.List1[J1.AppCfg], J1.AppCfg). The class contract from #2035/P11f is that every runtime message names a type through PyFormat.PyTypeName` (43f2d3a routed the missing-field message). The fix is to translate the library exception (type + path) into a python-named message rather than pass it through. TypeNameMessageSourceScan can't see this because the names come from the BCL at runtime.

[antonsynd]

Batching 2026-09-30 @ db8e05b — charter .claude/plans/remediation-round-2026-09-20-batching.md §3.27, P32 — typed-load doors (order N21, after P11g).

Contract: the typed json/yaml/toml doors share ONE naming rule (source ↔ member) and ONE message channel (python-spelled type names, python-shaped errors), and accept the same target shapes. Fidelity-scope: type names in messages are COMPARED (R-CF); message text beyond the name is DEVIATION (R-CI) — cells assert the type name and the exception TYPE, not library prose. After P11g. This cell: translate the library exception (type + path) into a python-named message rather than pass ex.Message through. Lane / reach: message · program. Class tracker: #2136. No seam hypothesis — the plan measures the seam.