Allow gds__free after default pool cleanup

[dand-oss]

gds__free() can be reached after the default memory pool has been cleaned up during process exit. Dereferencing the pool at that point crashes release builds. A guard through getDefaultMemoryPool() is insufficient in debug builds because that helper asserts that the default pool still exists; the assertion logging path itself re-enters pool-dependent code after cleanup.

Check MemoryPool::defaultMemoryManager directly and skip the deallocation when the default pool is gone. The block is intentionally left to the operating system at that stage, and gds__free continues to return zero.

Independently reproduced on Linux x86-64 against the ASan/UBSan debug Firebird 5 client built with USE_SYSTEM_MALLOC=ON. A focused test compiled the actual production src/yvalve/gds.cpp, linked it with the other production client objects, called MemoryPool::cleanupDefaultPool(), then called gds__free(NULL) and exited immediately:

• Original code: ASan DEADLYSIGNAL/stack overflow through the debug pool assertion and logging path.
• Guard using getDefaultMemoryPool(): same failure, confirming the helper assertion defeats the null check.
• Direct default-pool check: exits 0 and prints PASS: late gds__free returned.

The patched current-master gds.cpp also passes GCC 16.2 C++20 syntax compilation and git diff --check. This is a focused late-cleanup reproduction, not an end-to-end WinGLUE shutdown run.