Narrow the broad except Exception handling in the validation subsystem

[LukasOro]

Raised in review of #114 (#114 (comment)). Verified against feat/validator-migration at b4e23ac.

There are 12 except Exception clauses wrapped around this package's own code:

Module	Count
compliance.py	4
instance_checks.py	2
generate.py, pattern_lint.py, pipeline.py, predicates.py, roundtrip.py, schema_checks.py	1 each

A validator that catches everything reports its own bugs as findings against the user's document, which is the worst possible failure mode: the user sees a FAIL naming their schema and has no way to tell it apart from a real violation.

The two concrete cases

roundtrip.py wraps embedded_properties() and schema_to_frame(). A bug in frame.py therefore surfaces as a roundtrip.generated FAIL against the schema under test. Narrow to jsonld.JsonLdError and SchemaResolutionError.

predicates.py:112-113 returns PropertyOutcome(status=DROPPED, ...) when jsonld.expand raises, which is the same status returned at :116 and :120 for a term that genuinely has no @context mapping. Only the detail string differs, so PredicateResult.dropped conflates "this property has no term" with "the JSON-LD processor failed". PredicateResult.errors (predicates.py:74) exists for exactly the second case: it is serialised at :84 and read at :194 in the ok computation, but nothing ever appends to it, so it can never affect ok.

That second one is not only cosmetic. #120 is about the dropped-property finding becoming a warning rather than a failure; a processor error must stay a failure, and today it is indistinguishable.

Work

• narrow each clause to the exceptions the wrapped code can actually raise, or let it propagate
• write PredicateResult.errors in the expansion-failure path and keep the outcome out of dropped
• where a broad catch is genuinely right (a self-test harness continuing past one bad fixture), say so in a comment rather than leaving it to the reader

Already fixed

mcp_server.py parsing inline JSON with no try and assuming a dict, also from that review comment, was resolved by 18a952c: _materialise writes the text through and lets the pipeline report the parse error, so there is no unguarded parse left on that path.