OCCT wasm artifact in monorepo appears to lack STL reader bindings (StlAPI_Reader not exported)

[0x46y]

Summary

When using the OCCT wasm artifact distributed in the bitbybit monorepo
(packages/dev/occt/bitbybit-dev-occt), STL import appears to be unavailable
because STL reader bindings do not appear to be exported.

Environment

• Repository: bitbybit-dev/bitbybit
• Artifact: packages/dev/occt/bitbybit-dev-occt/bitbybit-dev-occt.js (+ wasm)
• Browser: Chrome
• Observed on latest master clone (2026-03-04)

Actual behavior

STL parsing fails immediately.

Our wrapper diagnostics report:

No STL reader call succeeded. Candidates: none; Errors: no details

From static inspection:

• bitbybit-dev-occt.d.ts contains StlAPI_Writer
• but does not contain StlAPI_Reader
• searching the repository and TypeScript definitions also shows
  no exported STL reader bindings

Expected behavior

Either:

1. STL reader bindings are exported
   (e.g. StlAPI_Reader, RWStl, or equivalent), or

2. documentation clarifies that STL import is intentionally
   not supported in this OCCT wasm artifact.

Additional context

In our previous integration based on the repository below,
STL import was available:

https://github.com/bitbybit-dev/bitbybit-occt

STEP and IGES APIs appear to be available in the current monorepo
artifact and initialization succeeds, so the issue seems specific
to STL import capability.

Could you confirm whether STL import is intentionally excluded
from the current OCCT wasm build?

If not intentional, would it be possible to expose STL reader
bindings in a future build?

[0x46y]

Additional context

Even after isolating the STL import problem, we are seeing a
separate downstream issue related to volume computation for
STL-derived solids.

Related issue: #126

Issue #124 tracks STL reader binding availability in the
monorepo OCCT wasm artifact.

Issue #126 tracks reliability of volume computation after
repair / solidify workflows.