…results

`table_function_results` is a `Tables` map protected by `table_function_results_mutex`.
All 5 production accesses (`Context::executeTableFunction`,
`Context::clearTableFunctionResults`) take the mutex before reading or writing
the map. The `ContextData(const ContextData &)` copy constructor, however,
copied the map in its initializer list:

    table_function_results(o.table_function_results),

without acquiring `o.table_function_results_mutex`. When another thread was
mutating `o.table_function_results` under the mutex (e.g. inserting a new
table-function cache entry from `Context::executeTableFunction`), TSan
reported a data race against the unsynchronized read inside the copy
constructor.

Reported via STID 1003-358c (issue ClickHouse#104807). The truncated stack from the
AST fuzzer hit on PR ClickHouse#104479 (amd_tsan) showed:

  T762 (write, holding M0): Context::executeTableFunction ->
    std::map::__insert_node_at
  T748 (read, no mutex):    ContextData::ContextData(const ContextData&) ->
    std::map __copy_construct_tree

The fix follows the established pattern used elsewhere in this file
(`QueryAccessInfo::QueryAccessInfo`, `QueryFactoriesInfo::QueryFactoriesInfo`,
`QueryPrivilegesInfo::QueryPrivilegesInfo`): take the source object's
mutex and copy the protected field in the constructor body.

PR ClickHouse#94171 originally added `table_function_results_mutex` and locked the
production readers/writers, but did not update the `ContextData` copy
constructor. This fix closes that gap.

Also adds a regression test in `gtest_context_race.cpp` that races a
writer thread (`executeTableFunction`) against a copier thread
(`Context::createCopy`). Without this fix, the TSan build reports the
race; with the fix, the test passes.

CI report:
https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=104479&sha=42334bfbb7d48857ed6741a30fd2a876590b1dff&name_0=PR&name_1=AST%20fuzzer%20%28amd_tsan%29

Closes ClickHouse#104807

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>