An OCL invariant that evaluates to invalid passes silently #280

In the model-driven implementation, an OCL invariant whose body evaluates to invalid is not reported as a refusal. To the caller it looks the same as an invariant that holds.

Found while landing #89. DependencyEdge::providing was first written as p.provides->exists(s | s.key = surface). Pivot OCL reads provides as a map and iterates its keys, so s.key is invalid. E_UNKNOWN_SURFACE and E_DEPENDENCY_CYCLE then reported nothing on the very fixtures meant to trip them. Only the negative fixtures' parity test showed the gap. The fix was p.provides->includes(surface).

Any invariant with a typing slip like that passes silently on every input. The fixtures catch it only for the cases they cover.

Constraints.check should treat an invariant that evaluates to invalid (or throws) as a build-time error naming the invariant, not as a pass. A test should hold that: one deliberately ill-typed invariant over a known model should fail the check.