Fix get_device_properties() before DeviceImpl.__init__

TL;DR

• Classic API servers that call get_device_properties() before DeviceImpl.__init__ start again, as in 10.3.1, when their class declares no device properties or the server runs without a database. Fixes the 10.3.2rc1 regression that broke the lima-tango-server BackgroundSubstraction plugin.

Closes #791 (closed)

Key Facts

• Calling any bound C++ method, such as get_name(), before DeviceImpl.__init__ is undefined behaviour: pybind11 dereferences a C++ object that does not exist yet. Depending on memory, it returns an empty string, raises MemoryError, or crashes with SIGSEGV. That is why the reproducer from the issue fails with process=True but passes in-thread.
• The regression test therefore does not rely on that undefined behaviour. The test device overrides get_name() to raise until the base __init__ has run, so the test fails deterministically on the unfixed code.
• PropUtil.fetch_device_props_from_db_with_class_props_fallback() now takes the device instead of its name and reads the name only right before the database lookup. PropUtil is internal API, and this method is new in 10.3.2rc1, so no released signature changes.
• With an active database and declared device properties, the name is still needed. Calling get_device_properties() before DeviceImpl.__init__ in that case still hits the undefined behaviour above, the same as in 10.3.1.

Caveats

• Not addressed here: get_name() and other bound methods on an uninitialised DeviceImpl should raise a clear error instead of undefined behaviour. This affects all bound methods and is a bindings change, tracked in #792 (closed).
• No news entry: the regression never shipped in a stable release, and for 10.3.2 users the behaviour matches 10.3.1.

🤖 Generated with Claude Code