fix(ontology): rebuild stale class URIs in OWL/R2RML/Digital Twin generation and persist Constraints tab

[benoitcayladbx]

Reopened against 0.9.0 after develop was deleted. GitHub cannot reopen #147 (closed PR + missing base), so this is a successor of #147 with the same commits. Original author: @jeremiaspf. Please rebase onto current 0.9.0 before review — expect conflicts.

Note for rebase: POST /ontology/constraints/save|delete is obsolete on 0.9.0 (legacy constraints migrated to SHACL; unit tests assert those endpoints no longer exist). Keep the stale-URI reconstruction in OWL/R2RML/Digital Twin; drop or rewrite the constraints persistence against the SHACL path.

---

What

Continuation of the "stale class URI after Base URI change" problem fixed for the reasoning engines in the companion reasoning-engines PR (fix/reasoning-lakebase-dialect-and-stale-uri), applied here to ontology/mapping generation — plus an unrelated persistence gap in the Designer's Constraints tab that a couple of these fixes depend on.

Stale-URI reconstruction, three places:

• OntologyGenerator._resolve_uri: when given a full URI (not a simple name) — as happens when the Expressions & Axioms editor sends a class/property's stored URI — it now checks whether that URI starts with the domain's current Base URI, and if not, extracts the local name and rebuilds it against the current Base URI. Before this, an axiom referencing a stale class URI no longer matched that class's own owl:Class declaration in the exported OWL, leaving the axiom effectively orphaned.
• R2RMLGenerator: reconstructs a mapping's class URI the same way before generating its TriplesMap, and looks up the class's data properties using the resolved URI rather than the original. Before this, mapped instances got an rdf:type pointing at the stale URI — disconnected from the real class — and their data properties weren't found either.
• DigitalTwin graph construction: same reconstruction when building the visual graph, so instances of a re-based class attach to it correctly instead of appearing disconnected.

Constraints tab had no backend to save to. Adds POST /ontology/constraints/save and POST /ontology/constraints/delete, which persist/remove an entry (by index) in domain.constraints — entity disjointWith/equivalentTo and relationship cardinality/functional/inverse-functional/symmetric/transitive. Before this, the Constraints tab UI accepted input but had nowhere to send it, so nothing was ever saved.

ReasoningService didn't consume Constraints tab data at all. Adds _get_constraints(), reading domain.constraints (where the tab's data actually lives, via the new endpoints above) in addition to the property's internal characteristics field (which in practice the UI never populates). Before this, marking a relationship Transitive or Symmetric in the Constraints tab had no effect on graph reasoning — the transitive closure / symmetric expansion pass only looked at a field nothing wrote to.

Why

Same root cause across the first three files: modules that trust a stored uri/iri field literally instead of treating it as derivable from (local name, current Base URI). The Constraints-tab gap is separate but directly blocks the SWRL/graph-reasoning fix from being meaningfully testable, since without persistence there's nothing for _get_constraints() to read.

How to test

1. Rename a domain's Base URI after creating a class, then: save an axiom referencing that class from Expressions & Axioms and export the OWL (URIRef should match); run a mapping targeting that class and inspect the generated R2RML/loaded triples (rdf:type should point at the current-Base-URI class); open the Digital Twin view (instances should attach to the class).
2. Open the Designer's Constraints tab, add an entity or relationship constraint, reload the page — it should still be there (previously lost).
3. Mark a relationship Transitive (or Symmetric) in the Constraints tab, run graph reasoning, and check the transitive closure (or symmetric pairs) actually materialize.