fix(connection): keep the UDF close() error when the UDF runs on the query thread

[zahariash]

This work was produced with the help of language models.

close() called from a UDF while its connection runs a query should raise "close() cannot be called from a UDF while the connection runs a query." It raises "close() cannot be called from a call on the same connection." instead whenever the UDF runs on the thread that issued the query: that thread's stack then holds the connection's own call below the UDF marker, and close() checks for the call first. On main this already happens when a constant argument is folded while binding (RETURN closer(1)). With LadybugDB/ladybug#1297, which runs a one-thread task on the calling thread, it also happens for a UDF over rows, and test_close_with_query_in_flight[close_from_a_udf] fails. A UDF on an engine worker thread is unaffected. The close is refused either way; only the message is wrong.

Fix. The same-thread check uses the UDF message when a UDF was entered after the connection's call (_called_from_udf), as the worker-thread path already does.

Tests. A new close_from_a_folded_udf scenario runs RETURN closer(1) with a UDF that closes its connection; it fails on main without the fix. With the fix, test_connection_close.py passes against ladybug main and against LadybugDB/ladybug#1297, and the rest of the suite (without the torch-geometric and JSON-extension tests) gives the same results against LadybugDB/ladybug#1297 as against main.