Function toCacheDataStore

Adapt a parsed store (an IfcDataStore from @ifc-lite/parser, or anything else matching ParsedIfcStore) into the CacheDataStore shape BinaryCacheWriter.write requires. This is the conversion the @ifc-lite/cache README's quickstart needs and previously didn't show — parseColumnar's return type and write's parameter type differ in the schema/schemaVersion key and its string-vs-enum representation, so passing a parsed store straight to write doesn't typecheck (issue #3759).

The one thing this does NOT do is materialize properties/quantities. For a STEP-parsed store those tables are empty by design — properties resolve lazily on demand — and this adapter serializes exactly what the store carries, so a cache written from a STEP parse has an empty property/quantity table too. See the @ifc-lite/cache package docs and docs/guide/querying.md for what that means for a cache-restored model.

entityCount falls back to entities.count when the store leaves it at 0. It is a header field the reader hands straight back to callers, and the viewer's write path carried this fallback inline before it moved onto this adapter. One difference from that inline copy, deliberately: it read entities?.count || 0, so a store carrying no entities at all still wrote a header claiming 0 entities. entities is required on ParsedIfcStore and a store without it cannot be serialized in any case, so this throws there instead of writing a plausible wrong count.

The entity index IS carried over: store.entityIndex already satisfies CacheEntityIndex structurally, so dropping it only cost callers the section (and with it the ability to re-attach lazy accessors on read, which is the very remedy the README recommends for the empty property tables).