Resolve physicalName in servicelevel freshness and retention checks

[erikgrip2]

Fixes #1488.

datacontract test's freshness and retention checks read the relation by the schema object's logical name; every other check resolves physicalName via to_schema_name(). A contract whose object name differs from the relation name — e.g. a versioned dbt model, aliased to <model>_v<n> — failed while all schema checks in the same run passed against the correct relation:

│ failed │ Freshness of events.ts < 1h │ ts │ Could not read model 'events': events │

datacontract export sodacl emitted its servicelevel blocks under the logical name the same way.

Changes

• Engine: a _resolve_sla_element helper folds the element split, the model existence gate, and name resolution — the object via to_schema_name() (keeping the kafka carve-out, which reads the Spark SQL view by logical name), the property via its physicalName. Both _freshness_check and _retention_check use it.
• Sodacl export: a _resolve_physical_names helper of the same shape, used by both servicelevel builders.
• The postgres servicelevels fixture now has an object name that differs from physicalName, so the e2e can distinguish "measured and stale" from "could not read the table"; it now also asserts the freshness diagnostics (age_seconds).
• New unit tests for both layers: resolution, fallback without physicalName, kafka.

Behavior notes

1. Reported names become physical for servicelevel checks (Check.model and the check display name) — consistent with what schema checks already report, but different from the sla.element spelling.
2. Row filters (--filter/--filters) now apply to servicelevel checks when physicalName is set. Filters are normalized into a mapping keyed by physical name, and the servicelevel specs' logical-name key never matched, so they silently ran unfiltered.
3. If the logical name happened to also name a readable relation, freshness previously measured that (wrong) table silently; it now measures the right one.
4. File servers (local/s3/gcs/azure): the duckdb views are registered under the logical name, so a contract with a differing physicalName already fails every schema check there; servicelevel checks now fail consistently with them instead of accidentally measuring the logical-name view. (Whether those views should be created via to_schema_name() instead may deserve a separate look.)

No change for contracts where physicalName is unset or equals the name.

Testing

• New unit tests fail before the fix and pass after.
• The postgres e2e fails pre-fix with Could not read model '<logical name>' and passes post-fix with freshness measurement diagnostics.

---

• Tests pass (uv run pytest)
• Code formatted (uv run ruff check --fix && uv run ruff format)
• Docs updated (if relevant)
• CHANGELOG.md entry added

🤖 Generated with Claude Code