tp: prove StringPool read path is concurrent-safe under locking (#7344)

Adds two ThreadSanitizer stress tests proving the StringPool read path
is safe for the multi-connection design, where string columns are read
on every query thread:

 - ConcurrentReadsNoInterns: 8 threads concurrently Get()/GetId() a
   finalized pool (small, block-spanning and >1MB large strings).
 - ConcurrentReadsWhileLockedInterns: with locking enabled, reader
   threads do lock-free Get() of pre-existing ids while writer threads
   continuously intern ~2KB strings, forcing several real 4MB-block
   allocations during the read window (the new-block publication path),
   plus occasional large-string appends. The test asserts the bytes of
   every pre-existing id stay intact and self-validates that block
   growth actually occurred.

No production fix was required: the lock-free Get() is safe against
concurrent interns because |blocks_| is a fixed array that never
reallocates (a new block writes a different slot), block bytes are
written forward-only before the Id is published, and large strings are
fully mutex-guarded. Documents this concurrency contract on
set_locking() — including that concurrent interns from multiple threads
are serialized by the mutex and supported (the prior draft contract
wrongly stated otherwise).