fix(reasoning): support Lakebase/Postgres dialect and rebuild class URIs against the current Base URI

[benoitcayladbx]

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

---

What

Two independent problems in the four reasoning-rule engines (Aggregate Rules, Decision Tables, SPARQL Rules, SWRL), found while running 0.7.1 in production:

1. Rules stop finding their target class after the domain is re-based.
When a domain's Base URI changes after a class already exists, that class can be left with a stale uri (the old Base URI) in its stored field. AggregateRuleEngine, DecisionTableEngine, SPARQLRuleEngine and SWRLEngine all trusted that stored uri as-is to find a rule's target/result class. All four now reconstruct the URI from the class's local name against the domain's current Base URI instead, matching what the rest of the codebase already does in this situation.

2. Numeric comparisons fail entirely against Lakebase (Postgres).
SQLHelpers's numeric-cast helper (used by all four engines wherever a rule compares a value numerically — an Aggregate Rule threshold, a Decision Table numeric condition) used TRY_CAST, which doesn't exist in PostgreSQL. Any such rule failed outright once the graph was stored in Lakebase. SQLHelpers.to_number() now takes a dialect parameter; on "postgres" it emits a CASE WHEN <regex validates numeric> THEN CAST … ELSE NULL END instead.

Two smaller, engine-specific fixes rode along because they touch the same functions:

• AggregateRuleEngine: inferred triples were only computed when materialize=True. An Aggregate Rule with a Result Entity configured but previewed (Run, not materialized) always showed 0 inferred triples even with matching rows. Now computed whenever a Result Entity is configured, consistent with the other rule engines.
• DecisionTableEngine: an input column left without an associated property (blank mapping) generated a SQL condition referencing a table that was never joined, raising missing FROM-clause entry. That column is now skipped instead, and the rest of the row still evaluates.

Why

All four are silent-failure modes: a rule that looks correctly configured in the UI either returns nothing or throws a raw SQL error, with no obvious link back to "the domain was renamed" or "the graph lives in Lakebase."

How to test

1. Create a domain, add a class, change the domain's Base URI, then create an Aggregate Rule / Decision Table / SPARQL Rule / SWRL rule targeting that class — before this fix, the rule returns 0 results/inferred triples; after, it finds the class normally.
2. Same setup but with the triple store on Lakebase, and a rule with a numeric threshold/condition — before this fix, running the rule raises a SQL error; after, it evaluates correctly.
3. An Aggregate Rule with a Result Entity, clicked "Run" without materializing — before, 0 inferred triples shown even with matching data; after, the preview shows them.
4. A Decision Table with one input column left unmapped — before, running it raises missing FROM-clause entry; after, that column is ignored and the rest of the table evaluates.

Happy to add/adjust automated tests for any of these if that's useful — wanted to get the report and the fix out first rather than block on writing a full suite against your test fixtures.