fix(emf): remove the two things that would break an examiner's import

[ExtraToast]

Part of #132, and deliberately does not close it.

What this branch does

#132 asks for a clean Eclipse import to be proved by hand. That needs a person at the IDE, which is why the issue carries no status: ready-for-agent and why this leaves it open. What it does is remove two of the failures the issue predicts, so that session confirms rather than debugs.

m2e had no lifecycle mapping for exec-maven-plugin, which is how both metamodels generate their typed Java. Without one an import reports "Plugin execution not covered by lifecycle configuration" against every such execution, and a grader meets a red workspace before reading a line of the model. The mapping is declared in pluginManagement: Maven ignores it, m2e reads it. runOnIncremental is false, because regenerating a metamodel on every keystroke helps nobody and a full build still runs it.

#87 made this worse a few hours ago without noticing, by adding a second execution for the target metamodel. The issue named the risk against one generator and there are now two.

The generated sources do not exist at import time. build.properties names target/generated-sources/emf/ as a source folder, and on a clean clone that directory is not there: import first and the workspace opens with every reference to a generated package unresolved. emf/README.md now opens with the terminal build and says why it is needed, which is the second acceptance criterion taking its own "or" branch.

The README also notes that five of the six modules are eclipse-plugin packaging, which m2e maps through the Tycho configurator, so the importer may offer to install a connector and ask to restart.

What was checked, and what was not

Every file the instructions name exists: emf.target, model/skeleton.ecore, model/empty.xmi, model/skeleton.ocl, model/notes.xmi, identity.launch and file.launch.

Nothing here proves the import. Whether the target platform resolves, whether the OCL document reports skeletonHasAnApplication on empty.xmi, and whether the two launch configurations write their output are all still open, and all still #132's.

Verification

./mvnw -B -ntp verify from emf/ exits 0, so the lifecycle-mapping block is inert to Maven, which is the point of it. Root npm run verify green at 782 tests.

[github-actions]

Shape

bucket	files	additions	deletions
documentation	1	+10	-1
tooling	1	+31	-0

Coverage

Baseline: main @ 21cba92.

metric	this branch	main	diff
statements	99.20%	99.20%	0.00
branches	96.56%	96.56%	0.00
functions	100.00%	100.00%	0.00
lines	99.13%	99.13%	0.00

This pull request changed no covered line.