Lifetime of dynamic-library related resources, tied to static object instance.

Description
Specifically on Linux platform.
Dynamic memory allocations by dxil are released when the dynamic library is released.
A quick look in the DXC source appears to show this happens in the destructor of a static object instance in DXC.

This causes issues when doing custom memory management (memory leaks reported).
Also, by the time those allocations are freed (app exit), the custom memory-manager no longer exists. Causing a segmentation fault.

On Windows platform this is not an issue because the lifetime of the static is bound to the DXC DLL whereas on Linux the dxil dynamic-library appears to be loaded in global space.

Steps to Reproduce
On Linux:

• Overload global new operator and count allocations
• Initialize DXC
• Use DXC API
• Close and release DXC
• Check allocation count (Count > 0)
• Exit app

Actual Behavior
Not all allocations are freed after closing and releasing DXC.

Environment

• DXC version 2025.02.20
• Host Operating System Ubuntu, ArchLinux

No source files or tests are named. Start by reproducing the Linux allocation-count scenario, then trace DXC and dxil dynamic-library teardown to identify where the remaining allocations are released. Done means resources are released before the custom memory manager is destroyed, with no leak count or exit-time segmentation fault.