Read the composition checks from the Effective Intent, not from each Shared Intent level by hand #276

Split from #201, which listed it as "the composition checks move onto the Effective Intent".

src/check/composition.ts answers the rules a Platform document and the project files answer together. It reads each project as authored (ProjectIntentDocument), not as lowered (EffectiveProject). Because the eight Shared Intent families can sit at three levels, it walks those levels by hand:

• edgesOf gathers dependsOn from the header, the Application and each Process;
• grantRefusals runs once per level;
• effectiveCutover resolves cutover across the three.

Each such walk is a second lowering, which drifts from the real one the first time a family's rule changes.

What reading the Effective Intent would need:

• A way back to the declaring site. A refusal points at the authored path, at the level the author wrote the field (spec/v1/10-project-intent.md#shared-intent). The lowered form holds every family on every Process, so a refusal there would point at each Process instead of the one header line. The lowering would have to record where each value came from, or the refusal would have to map back.
• Both implementations. The Java checks (OCL over the metamodel) read the authored model too, so the move lands in emf/ in the same pull request, against the same diagnostics oracles.

The worked examples now exercise header and Application-level Shared Intent (knowledge-platform lifts cutover to the header and hindsight's site to its Application), so a regression in either walk is caught by the committed oracles.