Read a project's labels, run order and collection order as MATLAB writes them

[ww-mw]

A generated corpus of real project stores, and the three parser defects it found.

Why

Every store in the project suite was hand-typed from reading one real project —
the one thing test/parity/matlab/README.md says never to do. Over a thousand
lines of them agreed with the parser on three things that are false, and the
first real store disagreed on all three.

The three fixes

what	the bug a user saw
ReadOnly has a vocabulary per element: READ_ONLY/WRITABLE on a label <Info>, 1/0 on a category's. The old rule tested the attribute's presence.	A label the user added read back as one of MATLAB's own, so the project page drew it as a built-in instead of a custom chip.
"First in the chain" is spelled two ways — an explicit Value="HEAD", or no Extension at all on the first entry, which is what a freshly built project writes. The walk started only at the literal HEAD.	Startup files listed in reverse run order for the common store shape.
The label catalog and the working folders came back in store order, which differs per layout.	The same project read two ways, and the project page rendered working folders in whatever order the file held.

entryPoints is deliberately left unsorted: its order is the run order.

The corpus

test/parity/matlab/gen_project.m builds one small project carrying one of
everything the seven collection readers look for, converts it with
matlab.project.convertDefinitionFiles into all four DefinitionFiles formats,
and records what MATLAB itself says each one holds.

format	MetadataType	store docs	.prj
SingleFile	monolithic	1	yes
FixedPathMultiFile	fixedPathV2	66	yes
MultiFile	distributed	30	yes
Toml	—	0	no

230 files, 38 KB, every XML format an openable .prj — small enough to commit,
where the 108 MB project that found the first defect is not.

Ownership is recorded by refusal: no MATLAB property reports it, so the
generator tries to remove each definition on a throwaway copy and writes down
the error identifier (MATLAB:project:management:CanNotModifyReadOnlyLabel).
That makes the expectation MATLAB's answer rather than our reading of the same
bytes that were misread in the first place.

What the suite asserts

The three kinds of claim the .slx layout corpus makes — the layout on disk is
real, each format against MATLAB's truth, and the three XML layouts deeply
equal to one another. That last one is licensed by MATLAB: it is asserted only
because those three conversions reported no warning. Toml warns
MATLAB:Project:Issues:LabelDataLoss and is compared against its own record.

The hand-typed stores stay. What they cover is damage — a document that is not
XML, a File entity that is its own child, a chain that is a cycle — which a
real conversion cannot be made to produce.

drift.mjs regenerates the project corpus too, compared per format and per
section. project_truth.json holds no uuid and no timestamp, and two runs of one
release came out byte-identical, so every diff there is a real change of answer.

Verification

npm run verify green: 5195 tests passing, 174 files.