Remove __blasINTsize__ and decouple Type.cpp from LAPACK headers

[IvanaGyro]

Motivation

src/Type.cpp includes a LAPACK header only to initialize the public global cytnx::__blasINTsize__. That couples the core type translation unit to backend-specific LAPACK headers and caused the MSVC/OpenBLAS failure identified in PR #1109's review: Reference LAPACK 3.11 can expose C99 _Complex declarations when lapacke.h is included without the matching configuration.

A repository audit found no algorithmic use or test of __blasINTsize__. It is currently:

• declared in include/Type.hpp;
• defined in src/Type.cpp;
• exported by pybind/cytnx.cpp and re-exported by cytnx/__init__.py;
• recorded in the Python stub and the BLAS integer-size documentation/example.

The current representations are also inconsistent: the Torch backend assigns 32 while the documentation describes a byte count, and the Python stub hard-codes 4, which is incorrect for an ILP64 build. Internal linalg code already uses blas_int (and, where necessary, sizeof(blas_int)) directly. Python's numerical BLAS/LAPACK ABI probe is independent of this global.

The immediate Windows work can keep a narrow compatibility fix, but the long-term design should remove this global and the LAPACK-header dependency from Type.cpp.

Proposed work

• Decide and document the compatibility policy for removing the public C++ and Python __blasINTsize__ attribute (including whether a deprecation cycle is required).
• Remove the declaration and backend-dependent definition.
• Remove the pybind/Python re-export, stub entry, documentation page/TOC entry, and guide notebook example.
• If BLAS integer-width introspection is still required, expose it from a backend-scoped facility that does not make Type.cpp include LAPACK headers.
• Keep the existing Python BLAS runtime compatibility check working; it does not currently consume __blasINTsize__.

Acceptance criteria

• src/Type.cpp no longer includes lapacke.h, lapacke_config.h, or mkl.h.
• No __blasINTsize__ symbol remains unless an explicitly approved deprecation shim is retained.
• No algorithm or ABI check is converted to an untyped integer-width assumption; backend code continues to use blas_int/MKL_INT at the call boundary.
• CPU builds and tests pass with MKL and OpenBLAS on Windows and Linux, and the normal macOS build remains green.
• Python API/stub/docs changes are consistent and include migration notes if the removal is user-visible.

Related work

• PR #1109 review finding
• Windows build/release tracker: Track Windows builds and PyPI releases #1114

---

This issue was investigated and drafted by OpenAI Codex at IvanaGyro's request.