fix(test): create ModelTests before concurrent pool workers

[devtechedge]

Summary

When sqlmesh test runs with concurrent_tasks > 1 and a unit test sets vars.execution_time, ModelTest.create_test() was running on worker threads. That path can call to_datetime() / ttl_cache (time.time()) while another worker is starting or stopping a time_machine freeze, which produces IndexError: list index out of range (or similar) during test creation.

This moves ModelTest.create_test() onto the calling thread before submitting work to the pool. Workers only run the already-built tests. Creation stays inside the same try/finally that closes engine adapters so an invalid create_test still cleans up connections.

Fixes #6039

Test plan

• pytest tests/core/test_test.py::test_freeze_time_concurrent -v passed 20 consecutive times locally (race; single pass is not enough)
• CI green

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO

[cmgoffena13]

Looks pretty close, I didn't notice connections being created. So right after connections are created we should make sure all relevant code is in a try statement to properly cleanup connections. Thanks for picking this up so quickly!

P.S. Don't forget our PR checklist. I added it to your description.

[devtechedge]

Thanks @cmgoffena13 - addressed your review feedback in 4d515a7:

1. Moved the calling-thread create_test loop into the same try/finally that closes engine adapters, so invalid creates still clean up connections.
2. Added a NOTE that create could be a separate parallel stage later, as long as it does not overlap with runs.

Also updated the PR checklist for the style/tests/DCO items I ran.

[devtechedge]

Thanks @cmgoffena13 for the review and for taking the time to walk through the connection cleanup and concurrency details.

The feedback around keeping create_test within the same try/finally scope was especially helpful. It made me think more carefully about the resource lifecycle when test creation itself can fail. I also appreciated the note about keeping future parallel test creation separate from test execution.

This was a really helpful learning experience for me, both from the concurrency side and from seeing how the implementation should account for cleanup and future extensibility.

Glad we could get this merged and close out #6039. Thanks again for the guidance and review!