Opening field model loses IMDF door/accessibility semantics

[jillesvangurp]

Summary

Opening feature schema is currently modeled with legacy/non-standard fields (door as numeric tri-state, accessibility as a single string) rather than IMDF opening properties.

Evidence

• src/lib/imdf/featureCatalog.ts:186 defines door as a required number with enum -1/0/1.
• src/lib/imdf/featureCatalog.ts:194 defines accessibility as a single optional string.
• src/lib/imdf/archiveImport.ts:318-323 only accepts numeric door and string accessibility.

Why this is a bug

IMDF opening uses richer property types (e.g., structured door data and accessibility arrays). The current model cannot represent valid IMDF payloads and will drop or coerce data on import/export.

Reference: https://docs.ogc.org/cs/20-094/opening/index.html

Reproduction

1. Import an opening feature that contains structured door/accessibility fields per IMDF.
2. Inspect imported feature properties in editor state.
3. Observe fields are missing or collapsed into incompatible shapes.

Expected

• Align opening property schema with IMDF field definitions.
• Preserve full opening semantics during import/export and editing.

Impact

Data loss and reduced interoperability for opening/accessibility semantics.