Investigate Data Property Type Support in Schema Explorer

## Investigate Data Property Type Support in Schema Explorer

### Problem

The Schema Explorer sidebar displays JavaScript types (e.g., `string`, `number`, `boolean`) for data properties instead of the actual database-level data types. Users expect to see the native data types from their graph database (e.g., `xsd:integer`, `xsd:dateTime`, `xsd:float` for RDF/SPARQL).

### Goal

Investigate how data property types are resolved and displayed in the Schema Explorer, and determine what changes are needed to surface the database-native types instead of JavaScript types.

### Investigation Steps

1. Trace how property types are fetched from the database and transformed before reaching the Schema Explorer UI.
2. Identify where JavaScript type coercion occurs and whether the original database types are available or discarded.
3. Determine what changes are needed in the connector, schema sync, or UI layers to preserve and display native types.

### Test Data Requirements

Create RDF resources with the following characteristics to validate behavior:

- **Shared class** — All resources should be instances of the same `rdf:type`.
- **Multi-type literal** — A property that appears across resources with multiple unique `xsd` data types (e.g., one resource has `xsd:integer`, another has `xsd:float` for the same predicate).
- **Custom data type literal** — A property that uses a custom (non-standard) datatype IRI (e.g., ``).

### Expected Outcome

A summary of findings that includes:

- Where in the codebase the type information is lost or converted.
- Whether the database query responses include the native type information.
- A recommendation for how to preserve and display database-native types in the Schema Explorer.