Generate the class diagram and vocabulary tables from the metamodel #40

Parent

#35

What to build

Chapter 10's class diagram (its mermaid block and its drawio drawing), the closed-vocabularies table and the field tables are generated from the Project Intent metamodel as the Zod schemas in src/ declare it, and committed. They are generated from the TypeScript declaration because it is the one that survives the coursework implementation's sunset, never from the Ecore files under emf/. CI regenerates them and fails on a diff.

• The generator replaces the hand-kept layout tree in the class-diagram script. Relations the script used to leave undrawn (placeholder to grant, placeholder to exposure) are drawn, or listed by a stated rule, not by a hard-coded count in a test.
• Exporting the drawio drawing to SVG stays a documented manual step. A test checks that the SVG's embedded diagram equals the generated drawio document.
• Chapter 10 gains the Process field table it lacks today.
• For chapter 10, chapter 00's rule "where the two disagree the SVG is the diagram and the mermaid is what gets fixed" no longer applies: both are generated.

Parity

The generator reads the Zod schemas, or the committed descriptor they are checked against, and nothing under emf/. The course report's Ecore class diagrams are drawn from the .ecore files inside emf/ and are not part of this ticket. Because the descriptor oracle holds the Ecore metamodel to the same structure, the chapter's generated diagram is also a correct picture of the Ecore metamodel.

Acceptance criteria

• Adding a field to the schema changes the mermaid block, the field table and the drawio document in one regeneration.
• Hand-editing a generated table or diagram fails CI.
• An SVG whose embedded diagram differs from the generated drawio document fails its test.
• The generator has no input under emf/.

Blocked by

• Declare the Project Intent metamodel once and parse every example with it #38
• Write down the rules the compiler will be held to #30