[shivanathd]

Problem

When the bundled _lbug extension fails to import, get_pybind_module() swallows the ImportError, and ladybug falls back to the C API backend. The published wheels don't ship the C API shared library, so the user only sees this:

RuntimeError: Could not find lbug C API shared library. Set LBUG_C_API_LIB_PATH or download a shared lib ...

The real cause is hidden. On macOS it's usually a missing OpenSSL 3 runtime: the wheels link /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib, and they exclude OpenSSL on purpose (#724 in LadybugDB/ladybug, and the discussion in LadybugDB/ladybug#681). We hit this on an Apple-silicon Mac without Homebrew, running ladybug 0.19.0 under cognee. The message sent us looking for a C API library we never needed, when the fix was to install OpenSSL 3.

Change

• _backend.get_pybind_module() keeps the ImportError.
• The "Could not find lbug C API shared library" message now includes it. When the missing library is libssl or libcrypto, it adds a hint: install OpenSSL 3 (brew install openssl@3 on macOS).
• No behaviour change otherwise: the same fallback order and the same exception type.

Example message after the change:

Could not find lbug C API shared library. Set LBUG_C_API_LIB_PATH or download a shared lib (e.g. run LBUG_LIB_KIND=shared bash scripts/download_lbug.sh). The bundled _lbug extension, which is tried first, failed to load: dlopen(.../_lbug.cpython-312-darwin.so, 0x0002): Library not loaded: /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib ... Ladybug needs an OpenSSL 3 runtime; on macOS, install it with `brew install openssl@3`.

Tests

test/test_backend_errors.py covers:

• the message without a recorded import error (unchanged);
• the message with an OpenSSL import error;
• that a failed import is recorded.

ruff check passes on the changed files.