Function createDataAccessor

Bridge an IfcDataStore (produced by @ifc-lite/parser) into the abstract IFCDataAccessor the IDS validator consumes. The single canonical translation: viewer, MCP server, and the buildingSMART corpus harness (src/__corpus__/corpus.test.ts) all use this rather than re-implementing the projection.

Mirrors upstream IfcOpenShell/ifctester semantics: classification sub-reference walking, IfcExternalReferenceRelationship for non-rooted resources, length unit conversion, predefined property-set unwrapping, schema-driven attribute XSD types, USERDEFINED predicate substitution, partOf transitivity, etc.

propertyOverlay is optional and lets a caller with in-memory, not-yet-exported property edits (e.g. an IDS correction applied through the viewer's MutablePropertyView) have those edits reflected in getPropertyValue/getPropertySets immediately, without re-parsing the store. Every other read (attributes, classifications, materials, partOf) is unaffected — only the two property-reading methods below consult it.

entityVisibility is optional and, when supplied, makes the accessor answer for the session's EFFECTIVE model (#5184, #5249). getAllEntityIds and getEntitiesByType enumerate through the shared effective-entity accessor: tombstoned entities are excluded, overlay-created entities are included under their class, and a retyped entity is listed under its new class. getEntityType answers the same effective class, because the validator confirms every candidate through it. A created entity's attributes are read from its authored payload (see ./entity-visibility.ts). Omitting entityVisibility leaves both enumerations reading the parsed index unchanged.