Read a project store whole, and project it into a main page

[ww-mw]

A .prj is a marker file; everything about the project lives in the sibling resources/project/ store, read entirely by convention. This fixes five things that store says which were being read wrongly or not at all, adds the parts of a project that were never modelled, and projects all of it into the view model behind a project main page (rather than a table).

The five defects

Each made the viewer state something false about a real project.

	What was wrong
Nested member paths	A File entity's location is relative to its parent entity, not to the project root. Read verbatim, every file inside a folder reported a bare basename — utils/helper.m and a root-level helper.m produced the same row. 357 of monophonic_syntethizer's 372 members are nested.
Invented references	A path folder, a working folder and a project→project reference are all spelled type="Reference"; only the collection they sit in separates them. A scan across every collection therefore invented references: monophonic_syntethizer has none and was reported as referencing three.
The project root on the path	The root is on the MATLAB path, recorded as Ref="", and is normally the first folder MATLAB adds. Testing the Ref for truthiness dropped it from almost every project.
Two collections of one type	A real project carries both location="Root" type="Files" (its members) and location="ALM" type="Files" (artifact tracking). Matching on type alone assigned the member list twice and let store order pick the winner — and the ALM collection holds no member files at all, only a DIR_SIGNIFIER, so losing that race meant zero members.
The distributed layout	Not read at all. It carries no pointer documents: an entity's location and type are its filename.

On the reference fix, the collections whose meaning we model are skipped by name, rather than allow-listing the ones that hold references: that collection's spelling varies by release, and a missed spelling would silently drop real references, which is worse than the bug being fixed.

On distributed, both layouts now normalize to one Entity shape so every collection reader is layout-blind. A layout we cannot walk is reported through the warnings channel rather than guessed at — the readers would otherwise return a project that looks complete and is empty, the one outcome a user cannot tell apart from a fact about their project.

What was never modelled

Most of what a project actually is: entry points (shortcuts and the startup/shutdown files, including the run order the store encodes as a *Prev linked list and nothing else recovers), shortcut groups, the designated cache/codegen/startup locations, whether a label is MATLAB's or the project's own, and the declared metadata format.

The page

buildProjectPage projects all of it into a view model. A project is not a table: MATLAB opens no document tab for one, and the file tree a table would show is already in VS Code's Explorer. What is nowhere else is everything around the file list, so that is what a page shows. The grouping, the run-order split, the label usage counts and the coverage figure are facts about the store rather than presentation, so they are derived once here and are testable without a webview.

It lives beside the parser rather than in datamodel/display/ because moduleBoundaries.test.ts pins that folder to zero outbound edges, and a projection of ParsedProject needs its types.

Verification

Against two real stores, both now reading with no warnings:

	monophonic_syntethizer	soc_swhw
layout	fixedPathV2, 1166 metadata docs	distributed, 29 docs
members / labelled	372 / 197	7 / 5
path folders	88 (incl. the root)	3 (incl. the root)
hooks	1 startup, 2 shutdown in run order	1 shutdown
shortcuts	11, in 2 named groups	5, two of which target folders
references	0 (was 3, fabricated)	0

Those figures match the reviewed page mockup exactly. 4981 tests pass; npm run verify is clean.