fix(mappings): correct the XML-schema corpus figure, and say how it was wrong

[ako]

#259 shipped claiming no demo app contains an XML schema. It is
3 documents in 1 of 9 — OneHarness: XML_ECO, XMLRequest_Diagram,
XMLRequest_DiagramId.

How the zero was produced

grep -rl "XmlSchemas" <extracted app>     # 0 for all nine

That can only work for MPR v2, where units are files under mprcontents/.
OneHarness is MPR v1: its units live in the SQLite Unit.Contents blob,
where the type string is not greppable from the file. The grep silently answered
"does any file contain this string" instead of "does any project contain this
document", and returned 0 for a reason unrelated to the question.

The lesson is in the finding record now: read units through mprbson.units() or
the reader, never by grepping the extracted tree.

Nothing about the fix changes

Failing open on an empty list is still right — 8 of 9 apps have none, so an empty
list remains the ordinary case rather than evidence of a typo.

And the reader is now verified against the three real Studio Pro documents,
which is stronger than the synthetic unit that first established the $Type and
Name keys:

import mapping ScopeTest.IMM_X: xml schema "NoSuch.Thing" does not exist;
available: OneHarness.XMLRequest_Diagram, OneHarness.XMLRequest_DiagramId, OneHarness.XML_ECO

Correct module, correct names, read straight out of a v1 project.

What is corrected

Three code comments (mapping_customhandler.go, validate_mapping_sources.go,
mapping_source_resolution_test.go), the bug-test fixture header, and the
finding record in findings/sdk.jsonl.

While measuring this I also took the census that motivates it — across 327
import/export mappings in the nine apps:

source	mappings	authorable in MDL
JSON structure	250 (76.5%)	yes
message definition	74 (22.6%)	no — read-only
XML schema	3 (0.9%)	no

Docs-only plus comments; no behaviour change.

🤖 Generated with Claude Code